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ABSTRACT 


Many  military  applications  for  intelligent-tutoring  systems  focus  on  the  training  of 
procedural  skills.  However,  while  there  have  been  many  successful  research  efforts  into 
developing  tutoring  systems  for  specific  applications,  the  question  of  developing  general- 
purpose  ones  is  still  open.  Specifically  unsolved  is  how  a  lesson-authoring  system,  a 
program  written  to  help  a  novice  write  computerized  lessons,  can  be  made  both  general 
purpose  and  easy  to  use. 

MEBuilder  is  a  prototype  lesson-authoring  system  which  employs  an  object-oriented 
approach  to  solving  this  problem.  MEBuilder  combines  automated  object,  task,  and  lesson 
modeling  tools  with  a  library  management  system  to  allow  teachers  to  develop  simulation- 
based  procedural  trainers  on  nearly  any  subject.  Teachers  create  reusable  objects  which 
have  a  fixed  and  well-defined  behavior.  Then  by  using  the  power  of  means-ends  analysis, 
MEBuilder  helps  the  teacher  build  entire  tasks  with  these  objects  in  just  one  step.  With 
these  tasks,  teachers  use  MEBuilder’s  workbook  structure  to  create  a  lesson  containing 
several  exercises.  At  each  step,  MEBuilder’s  automatic  error  and  consistency  checking 
reduces  time  spent  on  testing  and  debugging.  MEBuilder’s  library  manager  ensures  object 
and  task  reusability.  This  thesis  explains  MEBuilder’s  design,  data  structures,  and 
interfaces.  It  also  presents  experimental  results  which  support  MEBuilder’s  methods  as 
being  more  efficient  and  authoring  systems  using  traditional  computer-aided  instruction 
(CAI)  techniques. 
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I.  INTRODUCTION 


The  standard  classroom  environment  contains  two  primary  roles:  teachers  and 
students.  However,  the  teachers'  role  is  multidimensional.  Teachers  must  present  lessons 
to  the  students,  monitor  their  performance,  and  develop  the  lesson  material.  Research 
efforts  into  Intelligent  Tutoring  Systems  (ITSs)  have  produced  various  computer-based 
models  for  these  three  teacher  roles.  However,  many  find  the  third  role,  that  of  developing 
the  lesson  material,  to  be  the  most  difficult  challenge  for  ITS  developers. 

Developing  lesson  material  is  a  specific  application  for  an  authoring  system.  Authoring 
systems  are  programs  that  produce  other  programs  in  either  a  programming  language  or  a 
scripting  language  for  use  by  another  computer  program.  In  addition,  authoring  systems 
hide  the  details  of  the  target  language  from  the  user,  so  the  user  does  not  need  to  know  how 
to  program  a  computer  to  use  it  (Heift,  1994,  p.  263).  There  does  not  yet  exist  a  truly 
general-purpose  authoring  system  for  an  ITS.  However,  there  have  been  several  successful 
research  efforts  in  widening  the  scope  of  authoring  systems. 

This  thesis  presents  MEBuilder,  a  prototype  lesson-authoring  system  for  procedural 
skills.  MEBuilder  authors  lessons  for  METutor,  an  ITS  shell  written  at  the  Naval 
Postgraduate  School  which  tutors  procedural  tasks  in  virtual-world  simulations. 

A.  THE  DESIRE  FOR  HANDS-ON  STYLE  TRAINING  BY  COMPUTER 

Military  applications  emphasize  learning  by  doing  (TRADOC,  1991).  However,  due 
to  a  lack  of  available  resources,  military  training  is  often  conducted  in  a  traditional 
classroom  setting.  With  respect  to  procedural  skills,  classroom  instruction  is  an  inadequate 
substitute  for  learning  by  doing.  Computer-based  simulations  provide  a  better  substitute. 
Simulations  provide  a  reasonable  hands-on  training  environment  while  not  requiring  many 
resources  (Psotka,  1987,  p.  5).  In  addition,  computer  simulators  are  flexible  enough  for  use 
in  many  applications. 
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Additionally,  computers  can  combine  simulations  with  intelligent-tutoring  techniques 
to  provide  automated  trainers  for  students.  These  trainers  have  many  benefits  for  students. 
Students  can  learn  at  their  own  pace  with  minimal  direct  supervision  of  a  teacher.  Trainers 
give  feedback  to  the  students,  so  the  students  are  freer  to  make  mistakes  without  risking 
damage  to  actual  equipment.  Simulation  environments  generally  provide  "discovery-rich" 
tools  that  let  students  explore  the  environment  unimpeded  (Barr,  1982,  p.  291),  which  help 
make  the  simulation  believable  and  fosters  greater  learning. 

Unfortunately,  these  trainers  tend  not  to  help  the  teacher  who  must  prepare  the  lesson. 
Simulations  are  difficult  to  build  and  test,  but  this  difficulty  is  alleviated  through  tools  such 
as  authoring  systems.  For  this  application,  an  authoring  system  should  allow  objects  in  one 
simulation  to  be  reusable  in  other  simulations.  The  system  should  be  flexible  to  allow  a 
teacher  to  make  adjustments  easily,  but  also  to  check  any  adjustments  to  ensure  consistency 
with  the  rest  of  the  simulation.  Finally,  the  system  must  save  time  for  the  teacher.  In  order 
for  the  authoring  system  to  be  effective,  it  should  be  based  on  a  modeling  technique  that 
works  well  in  simulations  and  that  teachers  can  readily  understand.  One  technique  that 
appears  promising  is  object-oriented  modeling. 

B.  OBJECT-ORIENTED  MODELING  AS  AN  ANSWER  TO  THE  NEED 

This  thesis  employs  object-oriented  modeling  because  it  provides  all  the  benefits  listed 
above  easily  and  efficiently.  Object-oriented  modeling  is  a  way  of  constructing  entities  in 
a  virtual  world  so  each  entity  maintains  its  individual  behavior,  and  interrelations  between 
entities  are  strictly  controlled.  An  example  of  using  objects  in  an  intelligent-tutoring 
system  application  is  presented  in  the  aircraft  preparation  problem  given  in  Appendices  C 
through  E.  The  pilot  and  the  aircraft  are  the  two  main  objects  in  the  lesson,  and  the  lesson 
describes  specific  rules  on  how  the  pilot's  actions  affect  the  aircraft. 

Object-oriented  modeling  has  four  beneficial  characteristics  -  identity,  classification, 
polymorphism,  and  inheritance  (Rumbaugh,  1991,  p.  2).  Identity  means  that  the  data  is 
partitioned  into  discrete,  distinguishable  objects.  Objects  in  a  virtual  world  for  a  flashlight 
repair  problem  might  include  the  flashlight,  its  bulb,  and  its  batteries.  Each  of  these  objects 
would  exhibit  behavior,  and  then  the  three  objects  share  behavior  as  a  whole.  Classification 
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means  that  similar  objects  can  be  grouped  together.  Polymorphism  means*  that  the  same 
operation  may  behave  differently  on  different  objects.  Inheritance  is  a  means  of 
establishing  a  hierarchical  relationship  among  objects,  such  as  the  relationship  between  the 
abstract  object  "vehicle"  and  its  refined  objects  "wheeled  vehicle"  and  "tracked  vehicle". 

By  using  identity  and  classification,  objects  can  easily  model  the  behavior  of  their  real- 
world  counterparts,  thus  providing  the  basis  for  computerized  domain  knowledge. 
Polymorphism  and  inheritance  help  reduce  the  size  of  the  data  by  minimizing  repetition  ~ 
all  the  information  common  to  vehicles  is  present  once  in  the  vehicle  description,  and 
refined  objects  only  contain  the  refinements.  Finally,  using  all  four  to  their  greatest 
advantage,  one  can  easily  create  a  wide  variety  of  situations  based  on  modifying  one  or 
more  objects  in  a  scenario  or  introducing  more  objects.  Thus  it  appears  that  an  object- 
oriented  modeling  approach  would  serve  well  as  a  basis  for  a  lesson  building  tool,  and  with 
such  a  model  building  an  accurate  representation  with  a  virtual  world  scenario  would  be 
simple  and  efficient. 

C.  MEBUILDER  -  AN  OBJECT-ORIENTED  LESSON  AUTHORING  SYSTEM 

MEBuilder  is  a  simple-to-use  but  powerful  lesson-authoring  system  built  using 
Quintus  Prolog.  Based  on  means-ends  analysis,  MEBuilder  was  specifically  designed  to 
address  the  needs  of  virtual- world  construction  while  providing  direct  access  to  the  existing 
METutor  ITS  platform  to  test  and  validate  lesson  material.  The  primary  features  of 
MEBuilder  include  object-oriented  modeling,  task  modeling,  and  lesson  modeling.  It  is 
important  to  note  that  METutor  is  not  object-oriented,  so  these  models  are  new  to  this 
platform. 

MEBuilder's  object-oriented  modeling  will  allow  a  teacher  to  construct  a  simple 
representation  of  the  make-up  and  behavior  of  any  object  the  student  must  manipulate.  In 
addition,  the  modeling  system  allows  the  teacher  to  create  virtual  characters  whom  the 
student  must  interact  with.  Its  task  modeling  allows  the  teacher  to  build  the  specification 
for  a  task  that  a  student  must  perform  and  test  the  object  models  to  ensure  that  the  task  is 
both  feasible  and  correct.  Finally,  the  lesson  model  provides  the  framework  by  which  a 
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teacher  may  specify  a  multitude  of  scenarios  and  levels  of  difficulty  so  a  student  may  learn 
the  basics  first  and  then  learn  advanced  concepts. 

D.  CONTENTS  OF  THIS  THESIS 

1.  Chapter  II  -  Survey  of  Related  Work  in  Lesson  Authoring 

This  chapter  will  present  other  efforts  in  the  field  of  Intelligent  Tutoring  Systems 
end  lesson  authoring.  It  will  discuss  the  factors  that  good  lesson-authoring  systems  must 
have,  and  explain  why  good  general-purpose  authoring  systems  are  so  difficult  to  build. 

2.  Chapter  ID  -  Tutoring  System  Virtual  Worlds  and  Object  Modeling 

Techniques 

This  chapter  will  present  object  modeling  as  a  solution  to  some  of  the  problems 
present  in  Chapter  n.  It  will  describe  the  benefits  and  pitfalls  of  object  modeling.  Finally, 
it  will  describe  those  features  that  a  lesson-authoring  system  must  have  to  effectively 
employ  object  modeling. 

3.  Chapter  IV  --  An  Introduction  to  the  MEBuilder  System 

This  chapter  will  present  the  design  and  philosophy  of  the  prototype  MEBuilder 
system,  emphasizing  the  specific  criteria  of  lesson-authoring  systems  that  MEBuilder 
satisfies.  The  chapter  will  discuss  in  abstract  terms  how  MEBuilder  represents  objects, 
employs  inheritance  and  other  object-oriented  design  techniques,  how  it  models  tasks,  and 
how  it  constructs  a  lesson  scenario.  It  will  also  describe  the  teacher's  interface  and  how  it 
makes  the  job  easier  for  the  teacher.  Finally,  it  will  describe  MEBuilder's  library 
management  features  whici.  help  track  all  the  lesson  material  produced. 

4.  Chapter  V  ~  Translating  an  MEBuilder  Lesson  to  an  METutor  Lesson 

This  chapter  will  discuss  the  relationship  between  MEBuilder  and  the 

underlying  tutoring  system,  METutor,  Version  29.  In  particular,  it  will  present  the  data 
structures  of  an  METutor  lesson  and  describe  the  algorithms  MEBuilder's  compiler  uses  for 
generating  them. 
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5.  Chapter  VI  -  Experimental  Results 

This  chapter  will  catalog  an  experiment  conducted  to  test  the  capabilities  of  the 
MEBuilder  system.  The  experiment  involved  a  class  of  students  in  artificial  intelligence 
charged  to  author  a  given  lesson  in  MEBuilder  and  a  traditional  CAl-style  system. 

6.  Chapter  VII  ••  Conclusions  and  Future  Research  Directions 

This  chapter  will  summarize  all  of  the  above,  and  will  describe  those  areas  in 
which  MEBuilder  is  presently  inadequate.  It  will  also  present  "hooks"  into  the  MEBuilder 
system  left  so  that  integrating  some  of  these  advancements  will  be  easier. 

7.  Appendices 

Appendix  A  contains  the  header  comments  to  the  source  code  of  the  MEBuilder 
system.  The  entire  source  is  not  given  because  it  is  several  hundred  pages  long.  The 
complete  source  is  available  in  a  separate  technical  report.  Appendix  B  contains  the  text 
of  the  User's  Manual  for  MEBuilder,  minus  the  appendices.  Appendix  C  contains  excerpts 
of  -n  MEBuilder  session.  Appendix  D  contains  example  data  files  produced  from  the 
MEBuilder  session  conducted  in  Appendix  C.  Appendix  E  contains  excerpts  of  an 
METutor  session  running  the  compiled  lesson  in  Appendix  D.  Appendix  F  contains  the 
details  of  the  conducted  experiment  --  including  the  task  given  to  the  students,  the  raw  data 
collected  from  the  experiment,  selected  comments  from  the  students,  and  selected  material 
produced. 
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IL  SURVEY  OF  RELATED  WORK  IN  LESSON  AUTHORING 


Many  successful  research  efforts  in  Intelligent  Tutoring  Systems  provide  lesson¬ 
authoring  features  of  varying  degrees.  This  is  because  many  researchers  recognize  that 
Intelligent  Tutoring  Systems  (ITSs)  with  a  fixed  knowledge  base  and  courses  of  instruction 
outdate  themselves  too  quickly  and  cannot  handle  any  special  needs  of  the  individual 
teacher  or  student.  However,  there  are  many  differing  opinions  over  what  makes  a  good 
authoring  system.  This  chapter  will  present  some  of  the  commonly  agreed-upon  traits.  It 
will  then  discuss  related  research  efforts  and  what  authoring  services  they  provide.  Finally, 
this  chapter  will  introduce  MEBuilder  and  describe  the  authoring  features  it  will  provide. 

A,  ELEMENTS  OF  A  GOOD  LESSON-AUTHORING  SYSTEM 

From  an  architectural  point  of  view,  authoring  systems  have  four  major  components 
(Elson-Cook,  1994)  -  components  that  construct  the  domain  model,  the  instructional 
strategy,  the  student  model,  and  the  communication  model.  Conversely,  the  ITS  consists 
three  primary  components  —  the  expertise  module,  the  student  module,  and  the  tutoring 
module  (Barr,  1982,  pp.  229-234).  The  goal  of  the  authoring  system  is  to  provide  each  of 
the  ITS  components  with  domain-dependent  information  -  and  typically  the  instructional 
strategy  and  expertise  module  interrelate,  as  do  the  communication  model  and  the  tutoring 
module. 

The  list  of  properties  of  good  authoring  systems  is  still  openly  debated,  and  new 
applications  seem  to  be  producing  newer  requirements  or  desires.  However,  there  are 
recurrent  themes  in  the  literature  that  are  consistent  with  the  interrelations  among  ITS 
components  and  authoring  system  components. 

First,  the  system  must  contain  "theory-rich",  not  "theory-neutral",  tools.  (Guralnik, 
1994,  pp.  235-236)  Theory-neutral  tools  are  those  that  place  the  burden  of  creating  the 
learning  environment  on  the  teacher.  They  tend  to  accent  the  lesson  interface  with  the 


student  without  providing  tools  for  assisting  the  teacher  in  creating  consistent  instructional 
strategies.  Theory-rich  tools  have  an  understanding  of  the  ITS  shell  to  which  the  system  is 
authoring.  This  way,  they  provide  means  to  help  the  teacher  formulate  strategies  and  insure 
their  completeness  and  consistency. 

Second,  the  authoring  system  must  provide  ways  for  the  teacher  to  encode  domain- 
dependent  error  feedback  to  the  students.  If  it  was  solely  left  to  the  ITS  platform  to  model 
some  basic  student  errors  such  as  misapplication  of  operations  without  any  domain 
influence,  the  chances  for  a  proper  diagnosis  of  an  error  is  slim  (Heift,  1994,  pp.  263-264). 
However,  at  some  point,  the  platform  must  be  able  to  provide  information  to  the  student  in 
words  that  fit  the  context  of  the  application.  This  information,  called  "evaluative 
feedback"  essential,  in  order  for  the  student  to  learn  the  material  being  taught  rather  than 
simply  learning  how  to  solve  a  computer-based  riddle.  (Heift,  1994,  p.  263)  This 
evaluative  feedback  is  an  example  of  how  domain  model  information  is  passed 
parametrically  to  the  instructional  model.  The  best  authoring  systems  make  this 
information  flow  as  transparent  as  possible, 

Third,  the  authoring  system  must  present  a  high-level  interface.  Most  teachers  will  not 
know  how  to  program.  Clearly,  the  wrong  approach  is  to  force  teachers  to  learn  to  program, 
and  that  a  better  approach  is  to  have  the  system  provide  high-level  tools  that  do  the 
programming  automatically.  (Jones,  1994,  p.  300).  However,  the  system  cannot  be  made 
so  simple  that  the  domain  of  potential  lessons  it  would  author  is  limited  (Feifer,  1994, 
p.l  98).  What  the  system  must  do,  then,  is  provide  many  powerful  features  in  a  manner  that 
do  not  overwhelm  the  teacher  nor  limit  his/her  options. 

Finally,  for  the  purposes  of  serving  procedural  tasks,  the  authoring  system  should  be 
flexible  for  use  in  multiple  domains.  This  does  not  imply  that  an  authoring  system  built  for 
a  specific  domain  is  bad.  It  certainly  is  possible  that  some  domain-specific  authoring 
systems  could  be  developed  that  still  provide  enough  flexibility  to  be  used  in  other 
domains.  However,  if  the  ITS  is  purely  domain-specific,  then  for  its  authoring  system  must 
be  a  completely  separate  entity  that  can  be  used  with  another  ITS. 
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B.  TYPES  OF  LESSON-AUTHORING  SYSTEMS 


1.  Domain-Specific  Authoring  Systems 

There  have  been  hundreds  of  successful  ITS  applications  that  provide  single 
domain  instruction  to  a  student.  Th  se  applications  cover  subjects  ranging  from  operating 
kraft  boilers  (Woolf,  1987,  p.  413),  tutoring  radar  mechanics  (Tenney,  1987,  p.  59), 
understanding  and  writing  Chinese  characters  (Ki,  1994,  p.  323),  and  reading  and  writing 
skills  (Carlson  and  Crevoisier,  1994,  p.  111).  All  of  the  above  systems  plus  many  others 
have  the  domain  knowledge  built  into  the  system,  so  teachers  cannot  use  these  ITSs  for 
teaching  other  subjects. 

Moreover,  some  of  these  ITS  platforms  do  not  provide  authoring  capabilities. 
Also,  for  those  that  do  provide  authoring,  the  authoring  system  is  embedded  in  the  ITS  and 
cannot  be  used  for  other  domains.  Therefore,  these  systems  fail  in  the  fourth  criteria. 

2.  Systems  Built  Using  General-purpose  Hypermedia  Platforms 

General-purpose  hypermedia  platforms  provide  excellent  environments  for 

teachers  to  build  powerful  tutoring  applications  (Moreland,  1994,  p.  748).  Several  such 
platforms  are  commercially  available.  However,  tutoring  systems  created  from  these 
platforms  can  fall  short  because  the  platform  does  not  have  built-in  tools  for  producing  a 
true  learning  environment  (Guralnik,  1994,  pp.  235). 

It  falls  upon  the  teacher  to  create  this  environment  within  the  context  of  the 
platform,  which  is  difficult  at  best  for  several  reasons.  First,  such  platforms  have  no 
knowledge  or  concept  of  pedagogical  objectives.  The  teacher  must  try  to  create  them  and 
hope  the  platform  can  convey  those  objectives  within  its  hypermedia  web.  Second,  they 
force  the  teacher  to  take  a  well-defined  task  and  map  it  to  sequences  of  user-interface 
objects.  In  effect,  the  teacher  must  become  a  programmer.  (Guralnik,  1994,  p.  236) 
Therefore,  these  systems  fail  the  first  criteria  we  wish  to  meet. 
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3.  Domain-independent  Programmed  Tutoring  Systems 

The  ventures  into  domain-independency  began  with  the  development  of  ITS  s 
that  required  the  teacher  to  write  the  lesson  in  a  programming  or  scripting  language.  The 
ITS  effectively  becomes  an  interpreter  of  the  teacher’s  program.  Examples  include  the 
PIXIE  system  (Sleeman,  1987,  pp.  247-248),  which  required  the  teacher  to  write  rules  in 
LISP.  PIXIE's  authoring  system  consisted  of  the  text  editor  used  to  write  the  program. 
Although  both  emphasize  domain  independence,  such  an  approach  fails  the  third  criteria 
for  evaluation. 

C.  OTHER  ISSUES  REGARDING  LESSON-AUTHORING 

A  major  concern  among  lesson- authoring  systems  is  time.  By  one  estimate,  it  takes  an 
average  of  100  man-hours  to  produce  one  hour  of  instruction.  This  time  is  the  combination 
of  implementing  the  domain,  student,  and  tutoring  models  -  it  does  not  even  include 
domain  research  since  it  assumes  the  author  is  already  familiar  with  the  domain.  (Murray, 
1994)  Several  other  projects  emphasized  that  authoring  tiir.e  per  hour  of  instruction  is  a 
concern  (Gescei,  1994,  p.  15;  Jones,  1994,  p.  299).  Any  successful  lesson-authoring 
system  must  find  ways  to  cut  into  this  implementation  time. 

Another  concern  is  that  any  hands-on  style  training  must  be  believable.  Simulations 
are  not  a  perfect  representation  of  reality  since  storage  space  limitations  will  always  force 
authors  to  leave  out  key  details.  Doing  so  runs  the  risk  of  making  the  simulation  appear 
canned,  which  will  reduce  the  effectiveness  of  the  lesson  (Feifer,  1994,  p.  198). 
Unfortunately,  this  is  a  difficult  statistic  to  measure  and  is  equally  a  reflection  in  the 
choreographic  abilities  of  the  author  as  it  is  a  function  of  the  tools.  However,  poorly 
designed  tools  can  hinder  the  author.  The  authoring  system  should  allow  teachers  to 
visualize  the  task  being  built  so  they  can  properly  evaluate  it  and  make  it  more  realistic. 


D.  METUTOR  -  A  MEANS-ENDS  BASED  INTELLIGENT  TUTORING 

SYSTEM 

The  first  decision  for  building  an  authoring  system  is  to  find  an  ITS  shell  that  either 
does  not  have  one  or  has  an  inadequate  one.  The  best  ITS  shell  is  one  designed  for  use  as 
a  general-purpose  ITS  capable  of  handling  a  wide  range  of  lesson  domains.  The  advantage 
is  that  the  target  representation  of  the  domain  material  is  known  in  advance.  Thus,  the 
lesson-authoring  system  behaves  as  both  an  interface  and  a  translation  routine  between  the 
lesson  as  the  teacher  sees  it  and  the  lesson  as  the  ITS  sees  it.  For  these  reasons,  METutor 
was  selected  as  the  ITS  shell  for  an  authoring  system. 

METutor  is  a  pure  means-ends  based  tutoring  system  developed  at  the  Naval 
Postgraduate  School  by  Neil  C.  Rowe  (Rowe,  1993,  pp.  317-323).  METutor  is  a  general- 
purpose  tutoring  shell  like  PIXIE,  except  that  its  data  representation  resembles  more  of  a 
database  than  a  programming  language.  Lesson  definitions  are  very  simple,  and  by  using 
the  power  of  means-ends  analysis  the  simplicity  still  provides  a  robust  platform. 

First,  METutor  only  required  the  teacher  to  describe  the  lesson  using  a  minimum  of 
seven  predicates  (the  four  standard  means-ends  predicates  -  recommended,  precondition, 
addpostcondition,  and  deletepostcondition  -  a  random-event  template  called  randchange, 
and  the  start  jtate  and  goal).  METutor  also  provides  seven  additional  interface-based 
predicates  that  allow  a  teacher  to  build  the  lesson  in  a  graphic  interface  system. 

Second,  METutor  uses  Prolog  facts  rather  than  LISP  notation  in  describing  the  rules. 
Although  LISP  has  a  simpler  syntax,  Prolog  facts  are  easier  to  read.  For  example,  LISP 
uses  parentheses  as  the  universal  grouping  symbol  for  program  statements,  data  lists,  etc. 
Prolog  uses  parentheses  for  grouping  fact  arguments,  and  square  brackets  for  grouping  data 
lists. 

However,  METutor  lessons  are  still  built  as  text  files  that  behave  like  interpreted 
programs.  The  teacher  uses  a  text  editor  to  write  the  lesson,  which  is  loaded  with  METutor 
into  a  Prolog  session.  Because  the  means-ends  space  can  be  very  complex,  some  logical 
errors  can  be  difficult  to  detect,  and  teacher  can  become  easily  bogged  down  by  simple 
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programming  errors.  Yet,  even  if  every  individual  operation  is  properly  specified  in 
METutor,  there  is  no  guarantee  that  METutor  will  derive  the  solution  that  the  teacher 
intended  and  there  is  no  guarantee  that  every  solution  the  teacher  intended  will  work  in 
METutor. 

Based  on  the  criteria  established  for  good  authoring  systems  and  the  above  description 
of  METutor,  the  authoring  system  must  provide  several  specific  capabilities  to  be  effective. 
First,  it  must  establish  explicit  entities  that  have  well-defined  and  consistent  behaviors. 
Second,  it  must  encapsulate  procedural  behavior  with  sequences  that  teachers  understand, 
that  the  system  would  translate  into  a  set  of  means-ends  rules.  Third,  it  must  provide 
facilities  for  re-using  repeated  information  so  that  the  teacher  can  save  time.  To  accomplish 
this,  the  authoring  system  requires  an  appropriate  modeling  technique  --  and  the  one  chosen 
for  METutor's  authoring  system  is  called  object  modeling.  Object  modeling  is  presented 
in  the  next  chapter. 
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HI.  TUTORING-SYSTEM  VIRTUAL  WORLDS  AND  OBJECT¬ 
MODELING  TECHNIQUES 


Most  of  the  sample  lessons  studied  using  the  platform  described  in  the  previous  chapter 
plus  others  (Woolf,  et  al.  1987)  present  a  virtual  world  to  the  student.  These  virtual  worlds 
contain  objects  and  actors  that  have  both  independent  and  interdependent  behaviors,  and 
the  student's  goal  is  to  satisfy  a  set  of  objectives  for  each  object  in  the  virtual  world. 
Normally,  virtual-world  designers  use  object-modeling  techniques  (Rumbaugh,  1991,  pp. 
57-91),  some  of  which  are  described  below. 

A.  OBJECT-MODELING  TECHNIQUES 

1.  Generalization 

Generalization  is  the  relationship  between  an  object  and  one  or  more  refined 
versions  of  it.  In  artificial-intelligence  terms,  generalization  is  similar  to  the  standard  is_a 
or  a_kindjof  relationship  between  objects.  Virtual-world  modeling  makes  extensive  use  of 
generalization  in  order  to  take  advantage  of  the  similarities  among  similar  objects.  For 
example,  if  all  cars  have  four  wheels  then  one  could  use  that  information  to  save  time  when 
describing  various  types  of  cars. 

2.  Aggregation 

Aggregation  is  equivalent  to  the  part_of  relationship.  An  aggregate  object  is 
treated  as  a  unit,  even  though  it  consists  of  many  lesser  objects.  Further,  aggregate  objects 
behave  according  to  a  part- whole  relationship  where  the  condition  of  a  part  of  the  object 
affects  the  whole.  Aggregation  also  describes  the  possesses  or  has_a  relationship. 
Implementation-wise,  there  is  little  difference.  But  conceptually,  hasja  implies  more  of  a 
temporary  ownership.  Part _of  tends  to  imply  a  permanent  ownership,  and  the  dysfunction 
or  lack  of  the  part  renders  the  whole  ineffective. 
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3.  Metadata 

Metadata  is  data  that  describes  other  data.  Among  the  uses  of  metadata  are: 
instantiation,  relating  a  class  of  objects  to  a  particular  instance  of  that  class;  summary 
information,  which  describes  a  set  of  information  about  an  object  using  a  single  fact;  and 
null  information,  which  describes  whether  or  not  the  information  is  known,  applicable,  etc. 

4.  Events  and  States 

Events  are  things  that  happen  at  some  time.  For  example,  Flight  45  departs  from 
Hartford  or  the  user  has  clicked  the  right  mouse  button  are  events.  Some  events  preceded 
other  event  while  other  events  might  be  completely  unrelated  --  for  example,  Flight  45  must 
depart  Hartford  before  it  can  arrive  in  Pittsburgh  but  neither  of  these  events  are  relevant  to 
the  user  clicking  the  right  mouse  button. 

The  state  of  an  object  k  a  set  of  values  that  the  object  holds  that  affects  it  overall 
behavior.  States  specify  the  response  to  input  events.  For  example,  if  an  airplane's  engine 
is  unserviceable  then  the  response  to  an  event  of  fly  this  plane  to  Pittsburgh  will  be  negative 
-  whereas  a  completely  operational  plane  will  perform  the  task. 

B.  USE  OF  OBJECT-MODELING  TECHNIQUES  IN  METUTOR  LESSONS 

METutor  makes  extensive  use  of  events  and  states,  but  not  generalization  and 
aggregation.  METutor  presents  the  state  of  the  virtual  world  to  the  student  at  each  turn,  and 
each  operation  the  student  selects  constitutes  an  event.  In  addition,  METutor  provides  for 
the  definition  of  random  events  that  are  triggered  either  by  the  start  of  the  lesson  or  by  a 
student's  action.  After  the  student  applies  his  chosen  event,  METutor  updates  the  current 
state,  applies  all  random  events,  and  shows  the  student  the  new  state. 

However,  one  shortfall  in  METutor's  modeling  of  states  is  that  there  is  no  precise 
relationship  among  mutually  exclusive  members  of  a  state.  For  example,  flashlight's  may 
either  be  on  or  off.  Naturally,  any  event  that  causes  the  flashlight  to  become  on  must  delete 
the  previous  fact  that  the  flashlight  is  off.  Unfortunately,  there  is  no  direct  way  to  specify 
that  “on”  and  “off’  are  opposite  states  in  METutor.  This  means  that  a  teacher  may  forget 
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to  specify  the  "delete  off’  parameter  in  this  event  and  METutor  will  likely  not  detect  the 
error. 

Because  METutor  uses  a  simple  Prolog-fact  structure  for  the  state,  its  lessons  have  a 
limited  sense  of  the  objects  contained  in  the  virtual  world.  Prolog  facts  use  symbols  as 
arguments  to  predicates,  and  teachers  assume  that  predicates  with  like  arguments  constitute 
a  combined  state  of  an  object  However,  there  is  no  direct  way  to  model  aggregation  other 
than  employing  a  programming  convention  that  aggregate  objects  refer  to  its  components 
via  the  possessive.  In  other  words,  let's  assume  that  a  teacher  writes  as  a  component  to  an 
METutor  fact,  disassemble(the, flashlight ’s,top).  METutor  does  not  recognize  that 
flashlight  is  an  aggregate  object  nor  does  it  understand  that  the  top  is  part  of  that  aggregate. 
The  flashlight's  top  is  simply  another  argument  set  The  drawback  is  that  the  teacher  must 
directly  specify  and  manage  these  component  relationships,  a  difficult  task  to  do  error-free. 

Similarly,  METutor  has  no  means  of  recognizing  that  two  objects  are  instantiations  of 
the  same  object  type.  For  example,  a  teacher  is  writing  a  firefighting  problem  where  the 
fire  team  leader  has  two  subordinate  teams  at  his  disposal,  called  red  team  and  blue  team. 
Both  the  red  team  and  blue  team  objects  arc  identical  instances  of  a  class  of  firefighting 
teams.  However,  in  METutor,  there  is  no  facility  to  describe  both  objects  using  a  common 
set  of  events  and  states.  Instead,  the  teacher  must  repeat  all  the  rules  for  both  teams  and 
directly  include  mutually  exclusion  clauses  to  prevent  the  two  teams  from  performing  the 
same  action.  The  potential  for  errors  is  great.  Teachers  could  very  easily  fail  to  specify  all 
the  rules  when  preparing  the  copy  for  the  second  team,  or  accidentally  insert  blue  instead 
or  red  somewhere  in  that  second  set.  Additionally,  in  a  larger  system  with  more  than  two 
like  objects  -  such  as  a  system  administrator  lesson  where  a  system  has  hundreds  of  users 
— ;  is  process  is  both  tedious  and  unnecessary. 

Finally,  METutor  lessons  don't  have  a  built  in  state  diagram,  so  there  is  no  direct 
temporal  relationship  of  states  visible  to  the  teacher.  This  means  that  if  the  teacher  is  not 
careful,  he  could  produce  a  lesson  that  has  unintended  solutions.  An  example  of  this  was 


a  case  where  a  student  wrote  a  lesson  for  a  fifteen-step  procedure  that  had  a  possible 
solution  of  no  actions1. 

C.  OTHER  BENEFITS  TO  USING  OBJECT  MODELING 

1.  Object  Re-Use  and  Customization 

A  well-defined  set  of  objects  could  serve  as  the  basis  for  an  entire  set  of  virtual- 
world  based  lessons.  For  example,  most  naval  firefighting  equipment  is  similar  among  the 
various  classes  of  ships.  Firefighting  teams  are  also  similar  in  make-up  and  behavior.  So 
by  defining  the  make-up  and  behavior  of  a  general  class  of  firefighting  teams  and 
equipment,  a  teacher  could  develop  a  series  of  lessons  in  firefighting  among  a  large  variety 
of  ships  without  having  to  repeat  information.  Since  virtual-world  descriptions  can  become 
quite  large  and  complex,  this  is  a  definite  time-saver.  Reusable  objects  also  provide  the 
teacher  with  the  comfort  of  consistent  behavior,  so  the  teacher  can  confidently  use  the 
object  in  any  lesson  and  count  on  its  behavior. 

Also,  subtle  differences  in  the  make  or  model  of  two  objects  could  be  sufficient 
to  desire  to  customize  the  model.  For  example,  the  Army's  AN/GRC-142  Radioteletype 
System  has  seven  different  models  -  GRC-142  through  GRC-142F.  However,  the 
differences  among  models  are  not  subtle  -  some  are  wholesale  component  changes,  and 
some  Army  units  had  special  versions  of  one  of  the  models  as  a  result  of  a  component's 
experimental  fielding.  Teachers  in  these  units  will  appreciate  an  ability  to  customize 
objects  for  local  use. 

2.  Encapsulation 

Encapsulation,  or  information  hiding,  protects  objects  from  unintended  change. 
It  will  allow  a  teacher  to  substitute  objects  in  a  lesson  while  preserving  the  behavior  of  the 

1.  This  actually  occurred  during  tests  on  the  first  prototypical  authoring  system  for  METutor.  A 
student  who  apparently  misunderstood  the  meaning  of  states  coded  identical  start  and  goal  suites  of 
the  lesson.  Even  though  the  lesson  as  written  worked  properly,  the  quickest  solution  was  to  do 
nothing. 
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other  objects  in  the  scenario.  For  example,  a  posed  problem  for  a  ship  refueling  problem 
might  involve  a  cruiser.  Then  a  second  problem  might  involve  a  battleship.  The  different 
ships  have  independent  behaviors,  but  their  relation  to  the  fueling  ships  does  not  change. 

D.  PITFALLS  TO  USING  OBJF.CT-MODELING  TECHNIQUES 

I.  Generalization  is  Not  Equivalent  to  Subclassing 

Object-modeling  is  not  an  easy  task,  and  even  in  the  well-defined  realm  of 
programming  languages  there  still  exists  heavy  debate  regarding  what  constitutes  a  valid 
class  and  object  hierarchy  (Lalonde  and  Pugh,  1991,  pp.  57-62).  The  concepts  of 
generalization  and  subclasses  are  not  equivalent,  meaning  that  an  Qjdndjaf  relationship 
between  two  object  types  does  not  necessarily  constitute  a  proper  class  hierarchy.  Lalonde 
defines  subclassing  as  "an  implementation  mechanism  for  sharing  code  and 
representation,"  whereas  generalization  is  a  "....specialization  relationship,  i.e.  it  describes 
one  kind  of  object  as  a  special  case  of  another."  Figure  1  describes  a  relationship  among 
data  structures  that  clearly  shows  the  difference  among  the  two.  Although  binary  trees  are 
clearly  a  special  type  of  directed  graph,  the  most  efficient  data  structure  to  implement  the 
binary  tree  is  a  node  with  two  son  pointers.  Directed  graphs,  meanwhile,  are  best 
implemented  using  an  adjacency  matrix.  Since  such  relationships  are  not  always  clear  to 
computer  specialists,  the  potential  to  confuse  a  relative  novice  such  as  a  teacher  is  high. 

This  problem  arises  in  modeling  objects  in  virtual  worlds.  For  example,  an 
electric-powered  car,  such  as  a  golf  cart,  is  a  kind  of  car.  Clearly  one  cannot  derive  the 
behavior  of  a  golf  cart  from  car  because  the  two  have  completely  different  engines.  A 
teacher  desiring  to  build  a  golf  can  object  must  survey  the  existing  subclass  hierarchy  to 
insert  properly  entities  such  as  golf  cart  Unfortunately,  there  is  very  little  any  object- 
oriented  environment  can  do  to  detect  and  correct  errors.  It  is  incumbent  on  the  teacher  to 
recognize  and  use  the  best  hierarchy  possible. 
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2.  Increased  Complexity  for  Simple  Lessons 


Lessons  that  are  very  simple  --  those  with  few  objects  and  a  small  number  of 
events  or  states  --  should  remain  simple  to  write.  Adding  object-modeling  inherently 
increases  the  complexity  by  requiring  the  teacher  to  define  the  model.  Therefore,  defining 
the  model  for  simple  objects  must  not  serve  as  a  deterrent  for  the  teacher. 


Generalization  Subclassing 


Figure  1:  An  Example  of  Differences  in 
Generalization  and  Subclassing  Hierarchies 


E.  TOOLS  NEEDED  TO  ADD  OBJECT  MODELING  TO  AN  AUTHORING 
SYSTEM 

Clearly,  in  order  for  an  authoring  system  to  reap  the  benefits  of  object  modeling 
without  becoming  an  excessive  burden  for  the  teacher,  it  requires  specific  object-building 
tools.  These  tools  must  serve  the  purposes  of  providing  a  simple  framework  for  defining 
the  generalization  hierarchy;  for  defining  aggregations,  events,  and  states;  for  specifying 
inter-object  relationships;  and  for  providing  immediate  error-checking  to  the  teacher.  In 


addition,  the  tools  should  guarantee  to  the  teacher  that  the  lesson  is  complete  and  accurate 
before  use  by  a  student.  But  most  importantly,  these  tools  must  abstract  the  teacher  from 
the  low-level  representation  of  the  objects  and  speak  to  the  teacher  in  a  language  that  he 
can  easily  understand. 

1.  Object-Modeling  Interface  Concept  -  the  Adventure  Game  Model 

Many  modern-day  three-dimensional  adventure  games  present  a  virtual- world  to 
the  game  player  as  if  the  virtual-world  were  a  stage  and  the  student  is  acting  in  a  role 
(Example:  Sierra,  1993).  This  conceptual  model  is  extremely  easy  for  a  teacher  to 
understand,  yet  still  provides  an  adequate  framework  for  building  all  the  other  tools 
necessary  to  construct  the  virtual  world.  Therefore,  one  good  way  to  assist  the  teacher  is 
describing  things  in  stage  terminology  -  a  cast,  a  set  of  props,  and  settings. 

The  cast  is  an  easy  model  to  demonstrate  how  the  tools  can  provide  yet  hide 
generalization  and  aggregation  to  the  teacher.  Typically,  a  cast  member  plays  a  role,  which 
is  a  subclass  of  a  character.  This  role  generally  exhibits  a  specific  set  of  behaviors  --  actions 
that  he  must  perform  to  respond  to  external  stimuli.  Roles  can  be  generalized  and  can 
maintain  or  possess  props  --  plumbers  and  electricians  are  ajdnd  of  handyman,  for 
example,  and  handymen  possess  tool  kits.  Once  a  teacher  defines  a  particular  role,  he 
instantiates  it  by  inserting  it  into  a  particular  virtual  world.  In  addition,  the  teacher  could 
specify  that  the  student  is  to  play  a  particular  role  and  perform  some  task  in  the  scene. 
Similarly,  stage  terminology  will  help  simplify  the  process  of  defining  props  and  settings 
for  the  teacher. 

2.  Object-Modeling  Tools 

The  above  paragraph  describes  how  a  platform  can  make  generalization  and 
aggregation  easier  to  model.  Events  and  states  also  have  properties  that  an  object-modeling 
platform  could  exploit  to  save  time  for  the  teacher. 
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a.  Mutual  Exclusion  of  States 

Most  potential  states  that  an  object  can  attain  are  mutually  exclusive  of 
other  states.  Previously,  this  thesis  presented  an  example  of  how  a  flashlight  could  not  be 
both  on  and  off  -  it  must  be  one  or  the  other.  Similarly,  a  fire  is  either  raging  or  out;  a  street 
light  is  either  green,  amber,  or  red;  and  the  chloride  level  of  the  water  in  a  ship  s  boiler  can 
have  precisely  one  value  in  the  range  of  0.0  to  1.5  parts  per  million.  Especially  regarding 
qualitative  values,  the  tools  use  these  teacher-defined  mutually  exclusions  and  ensure  all 
operations  involving  the  object  maintain  this  property. 

b.  Summarizing  Object  States 

A  car's  engine  could  contribute  hundreds  of  items  to  the  state.  In  many 
applications,  not  all  of  these  items  are  relevant  or  interesting  to  the  student.  For  example, 
if  the  fuel  injection  system  is  working,  the  student  probably  only  needs  to  know  that  it  is 
working  --  not  the  ten  or  twenty  different  state  members  that  make  up  the  fact  that  it  is 
working.  Providing  tools  to  describe  summaries  of  large  groups  of  data  will  not  only 
provide  greater  expressive  power  to  the  lesson  but  simplify  the  lesson  building  process  for 
the  teacher. 

c.  Modeling  Unknown  Information 

A  very  common  property  among  diagnostic  lessons  is  that  the  student  does 
not  know  all  the  information  that  is  true  in  a  state.  However,  any  lesson  could  have  a  need 
to  model  what  a  student  knows  or  should  know.  There  are  several  specific  properties  which 
make  knowledge  easy  to  model  and  thus  easy  for  tools  to  implement.  Moore  developed  a 
full  first-order  logic  theory  concerning  modeling  what  a  student  knows  and  what  actions  a 
student  takes  based  on  what  he  knows.  In  his  theory,  Moore  describes  things  known  and 
unknown  as  additional  members  of  the  state  influencing  the  end  result  of  the  theorem  being 
proven  (Davis,  1990,  pp.  390-391). 

Many  props  are  consistent  regarding  what  an  actor  would  know  or  not 
know  about  the  object.  For  example,  a  student  would  not  know  that  the  batteries  inside  a 
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flashlight  are  dead  just  by  looking  at  the  flashlight.  Instead,  the  student  would  need  to 
engage  in  a  series  of  steps  to  investigate  the  dysfunction  of  the  flashlight  and  thereby  soon 
discover  the  problem  with  the  batteries.  The  status  of  the  batteries  is  something  that  would 
normally  not  be  known  by  a  student,  so  the  object  model  of  a  flashlight  could  contain  an 
additional  flag  marking  the  battery  status  as  hidden. 

d.  Modeling  Objectives 

In  order  for  a  teacher  to  build  the  lesson,  the  teacher  must  be  able  to 
describe  what  the  objectives  of  the  lesson  are  so  the  ITS  platform  may  identify  when  the 
lesson  is  over  and  identify  points  where  the  student  is  failing  to  make  progress. 
Additionally,  the  teacher  must  identify  objectives  for  ail  the  other  actors  in  the  scene  so  that 
their  behavior  is  consistent  and,  to  a  degree,  predictable. 

e.  Modeling  Operations  and  Sequences  of  Operations  (Tasks) 

To  provide  a  useful  method  of  describing  the  actions  a  student  may  take, 
teachers  must  combine  a  student's  potential  objectives  with  a  description  of  atomic 
operations  that  cause  the  change  of  state  of  an  object.  Together,  the  platform  should  help 
the  teacher  describe  all  possible  sequences  of  atomic  operations,  or  tasks,  that  achieve 
those  objectives. 

Atomic  operations,  operations  that  a  teacher  decides  he  cannot  or  will  not 
break  down  into  subactions,  consist  of  several  components.  First,  operations  have  a  direct 
object  -  the  specific  object  being  manipulated.  Second,  operations  have  a  list  of  indirect 
objects  --  those  other  objects  required  for  performing  the  operation.  Third,  operations  have 
an  intended  effect  <•  the  specific  change  of  state  that  the  direct  object  will  attain  as  a  result. 
Finally,  operations  have  preconditions  --  the  required  states  that  all  direct  object  and 
indirect  objects  must  be  in  to  apply  the  operation.  With  these  atomic  operations,  the  tool 
has  enough  information  to  make  a  partial  assessment  of  what  actions  are  necessary  to 
achieve  a  given  objective  from  a  given  staring  state. 


F.  SUMMARY 


This  chapter  has  presented  a  brief  study  of  authoring  systems  for  ITS  platforms  and 
described  how  object-modeling  techniques  could  enhance  their  functionality.  In  addition, 
this  chapter  discussed  several  object-modeling  issues  and  described  how  an  authoring 
system  could  use  object  modeling  to  help  teachers  build  lessons.  The  next  chapter  will 
describe  MEBuilder,  a  prototype  authoring  system  for  METutor,  which  employs  object¬ 
modeling  techniques. 
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IV.  AN  INTRODUCTION  TO  THE  MEBUILDER  SYSTEM 

MEBuilder  is  a  lesson-authoring  system  written  entirely  in  Quintus  Prolog,  taking 
advantage  of  several  Quintus  Prolog  library  modules.  It  presently  uses  only  text  for  input 
and  output,  but  its  design  lends  itself  for  use  in  a  menu-driven  windowing  environment. 

A.  MEBUILDER'S  TOP-LEVEL  DESIGN  AND  PHILOSOPHY 

MEBuilder  consists  of  one  main  program  module  and  five  primary  submodules. 
Appendix  A  contains  the  header  comments  for  these  modules.  Its  overall  design  parallels 
that  of  the  Ada  Programming  Support  Environment  (DoD,  1983).  Not  only  does 
MEBuilder  provide  the  editing  capability  for  building  lesson  material,  but  also  provides 
library  services  that  cross-checks  the  lesson  material  for  consistency.  Figure  2  is  a  diagram 
showing  the  relationships  among  MEBuilder's  primary  modules,  its  primary  data  stores, 
and  the  external  tutoring  system. 

I.  MEBuilder  Lesson  Material  -  The  Three-Layered  Design 

The  three  modules  across  the  middle  of  Figure  2  indicate  the  three  modules 
corresponding  to  MEBuilder's  three-layered  lesson  design  -  the  three  layers  being  classes, 
tasks,  end  lessons.  The  purpose  of  this  design  is  to  maximize  code  re-use  and  reduce 
authoring  time.  The  intent  is  that  the  final  version  of  MEBuilder  would  come  with  whole 
libraries  of  classes  and  tasks,  and  the  focus  of  the  teacher  falls  solely  on  the  lesson  layer. 

a.  The  Class  Layer 

The  class  layer  is  where  the  basic  object  descriptions  lie.  It  corresponds  to 
the  class  data  structures  in  an  object-oriented  programming  language.  The  class  layer 
manages  the  primitive  attributes  and  values  for  all  MEBuilder  objects.  Classes  are  abstract 
entities  that  are  instantiated  during  lesson  construction. 
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6.  The  Task  Layer 

The  task  layer  is  where  the  primitive  sequences  of  operations  lie.  It 
corresponds  to  methods  in  an  object-oriented  programming  language.  A  task  is  an 
encapsulation  of  a  single  initial  condition,  a  single  goal,  and  a  method  to  achieve  the  goal 
without  external  stimuli.  The  method  consists  of  the  defined  primitives  from  the  class 
layer.  Tasks  are  also  abstract  entities. 

c.  The  Lesson  Layer 

The  lesson  layer  is  a  workbook  with  a  collection  of  concrete  problems  for 
the  student  to  solve.  The  lesson  consists  of  named  instances  of  classes  and  relevant  tasks 


24 


to  perform,  and  each  problem  provides  a  particular  initial  setting  and  objectives  for  the 
student  to  achieve.  Well  defined  classes  and  tasks  make  this  very  simple  to  accomplish. 

The  lesson  layer  also  provides  access  to  the  underlying  METutor  system. 
This  access  allows  quicker  testing  and  debugging  of  the  lesson  material. 

2.  MEBuilder's  Bottom-Up  Approach  to  Authoring 

MEBuilder  uses  the  three-layered  design  to  enforce  a  bottom-up  approach  to 
lesson  design.  Thus,  the  user  must  design  the  objects  first,  followed  by  the  tasks,  and 
finally  the  lesson  itself.  Appendix  B  contains  the  main  text  of  the  MEBuilder  User’s 
Manual  detailing  the  process.  Appendix  C  contains  an  annotated  script  run  demonstrating 
MEBuilder’s  main  commands. 

The  bottom-up  approach  has  several  advantages.  First,  MEBuilder  performs 
consistency  checks  at  each  step  to  ensure  that  changes  in  a  lower  layer  do  not  adversely 
impact  data  in  a  higher  layer.  Second,  MEBuilder  can  use  the  lower-level  information  in 
order  to  save  typing.  For  example,  when  building  a  task,  MEBuilder  provides  the  user  with 
menus  containing  all  the  appropriate  information  from  the  class  layer.  The  user  then  only 
selects  from  menu  items  rather  than  having  to  type  the  information  -  which  he  would  still 
have  to  insert  into  the  class  definitions  later.  Third,  MEBuilder  can  use  means-ends 
analysis  to  assist  the  teacher  in  building  tasks  and  lessons.  This  is  not  possible  without  a 
compl'  c  rt  of  class  definitions. 

acre  are  also  disadvantages  to  the  bottom-up  approach.  First,  it  is  difficult  for 
the  teacher  to  visualize  the  lesson  as  he  builds  it  Clearly,  if  the  teacher  has  a  complete 
library  of  objf  a  and  tasks,  he  will  spend  less  time  in  the  lower  two  layers  and  minimize 
this  effect.  But  the  worst  case  scenario  will  likely  be  the  norm. 

Second,  the  bottom-up  approach  is  vulnerable  to  modular  interface  problems. 
Tasks  that  individually  work  might  not  combine  well  in  a  lesson.  For  example,  two  task 
definitions  when  combined  into  the  same  lesson  may  cancel  each  other's  effects  or  become 
mutually  exclusive.  MEBuilder  currently  only  has  limited  capabilities  for  detecting 
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potential  interface  problems.  Therefore,  users  must  exercise  caution  when  building 
complex  scenarios.  Also,  all  tasks  defined  for  a  lesson  should  be  designed  as  disjointly  as 
possible  -  meaning  the  one  operation  should  only  appear  in  one  task. 

B.  MEBUILDER  MAIN  MODULE  -  "MEBuilder" 

The  main  module  performs  several  key  functions.  It  provides  MEBuilder's  command 
loops,  its  help  facility,  its  autosave  facility,  and  compilation  data  for  Quintus  Prolog. 

MEBuilder  has  four  command  loops  --  main,  task,  lesson,  and  problem.  The  main 
command  loop  is  self-explanatory.  The  other  three  are  special  loops  invoked  from  main 
which  have  specific  functionality.  The  relationships  among  the  loops  and  MEBuilder's 
three  layers  is  diagramed  in  Figure  3. 
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Figure  3:  Relationships  of  Command  Loops 
to  MEBuilder’s  Three-Layer  Lesson  Design 


MEBuilder  provides  a  very  simple  help  system,  future  versions  may  include  a  more 
context-sensitive  facility.  The  user  may  enter  the  help  system  from  any  of  the  four  loops 
and  query  for  information  on  any  command  or  on  various  topics. 
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MEBuilder's  autosave  facility  is  a  protection  mechanism  for  the  teacher.  After  each 
tenth  command,  the  entire  MEBuilder  database  is  save  to  an  autosave  file,  called 
"autosave.meb".  The  purpose  of  the  autosave  is  to  allow  the  user  a  chance  to  recover  to  a 
previous  program  state  if  for  some  reason  MEBuilder  aborts  without  warning.  A  special 
"restore"  command  exists  in  the  main  loop  which  restores  the  saved  environment. 
Currently,  the  autosave  facility  parameters  are  fixed  --  the  user  cannot  set  the  number  of 
turns  nor  change  the  name  of  the  target  autosave  file. 

MEBuilder  is  designed  to  be  run  as  a  stand-alone  system.  The  main  module  contains 
all  the  data  necessary  for  the  Quintus  Prolog  compiler  to  create  a  separate  executable  file 
from  MEBuilder. 

C.  MEBUILDER'S  LIBRARY  MODULE  -  "MEBuildLIB" 

MEBuildLIB 's  purpose  is  to  save  time  for  the  teacher  by  untying  his  hands  of  file 
management  In  MEBuilder,  each  class,  task,  lesson,  and  compiled  lesson  gets  its  own  file. 
This  makes  it  easier  for  the  teacher  to  access  them  at  will.  However,  there  is  a  clear  and 
defined  dependency  among  the  above  entities.  For  example,  a  class  is  dependent  on  its 
parent  class,  and  if  that  class  is  in  the  database  without  its  parent  then  the  inherited 
information  is  not  available.  Hence,  when  a  teacher  requests  that  a  particular  entity  be 
loaded,  all  other  entities  that  the  entity  depends  on  are  also  automatically  loaded.  Entity 
dependencies  are  defined  as  follows: 

•  A  class  is  dependent  on  its  parent. 

•  A  class  is  dependent  on  the  class  of  each  of  its  components. 

•  A  task  is  dependent  on  each  class  it  is  built  from. 

•  A  lesson  is  dependent  on  each  class  and  task  it  is  built  from. 

To  accomplish  this,  MEBuildLIB  creates  and  manages  a  special  library  subdirectory 
in  the  user's  working  directory.  This  subdirectory  holds  all  the  files  for  the  various  objects 
and  holds  one  special  directory-information  file  maintained  during  the  session.  The 
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information  file  is  a  Prolog  fact  file  containing  entries  for  each  entity  --  the  entity  name, 
type,  file  when  stored,  date  of  last  save,  and  dependencies. 

The  date  of  last  save  is  also  important.  MEBuildLIB  attempts  to  catch  potential  errors 
by  checking  these  dates.  If  a  class  has  been  updated  after  a  task  that  uses  it  was  last  saved, 
the  change  to  the  class  might  have  induced  an  error  in  the  task.  As  a  rule,  changes  in  a  class 
invalidate  all  tasks  and  lessons  that  use  it  (compiled  lessons  based  on  the  task  are  still  OK). 

D.  MEBUILDER'S  CLASS  DEFINITION  MODULE  ••  "MEBuildCLS" 

MEBuildCLS  is  a  simple  data  structure  manager  which  serves  two  important 
functions.  Its  primary  and  most  visible  function  is  to  build  class  definitions.  Its  second 
function  is  to  provide  the  other  modules  with  the  class  information  they  need  in  order  to 
perform  their  functions.  It  is  in  this  module  that  all  object  modeling  takes  place. 

1.  The  Class  Data  Structure 

a.  class_def{ <class>,  <parent  class>) 

Currently,  MEBuilder  only  handles  single  inheritance,  and  the  intent  is  for 
the  inheritance  to  model  the  ajcind_pf  relationship  only.  MEBuilder  recognizes  two  global 
classes  of  which  all  classes  must  descend  from  --  prop  and  character.  The  significance  of 
prop  versus  character  is  critical  for  tasks.  There  is  one  class _def  field  per  class. 

b.  component(<class>,  <component  class>,  <component  name>,  <tense>) 
Component  multifacts  encompass  both  the  a _part_of  relationship  among 

props  and  the  has_a  relationship  among  characters.  There  is  no  restriction  in  MEBuilder 
regarding  what  class  can  serve  as  a  component  of  what  class  except  that  the  user  must 
adhere  to  part-land  inheritance  and  circular  inheritance  is  not  allowed.  The  component 
name  primarily  helps  distinguish  among  like  components  of  the  same  class  -  such  as 
unique  names  for  the  four  wheels  of  a  car  If  there  is  only  one  component  of  a  given  type, 
the  name  should  equal  the  class.  The  tense  argument  helps  METutor  print  out  the  correct 
verb  forms  for  the  components  whose  name  does  not  follow  the  "ends  in  s"  rule. 
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c.  property  jset(<class>t  Kproperty  set  name>,  <domain> ,  <hideable> ) 
Property  jet  multifacts  describe  the  various  attributes  and  values  that  the 

class  can  take  on.  Collectively,  the  active  values  of  the  property  sets  constitute  the  object's 
total  state.  The  members  of  the  domain  are  mutually  exclusive.  For  example,  a  streetlight 
might  have  two  property  sets  --  "color"  with  domain  "red",  "amber",  and  "green";  and 
"persistence"  with  domain  "flashing"  and  "not  flashing".  Therefore,  a  light's  state  could  be 
red  and  not  flashing,  or  it  could  be  amber  and  flashing.  Currently,  domains  are  limited  to 
being  one  of  a  list  of  qualitative  values.  Future  implementations  may  include  the  ability  to 
specify  ranges  of  numbers. 

In  addition,  a  property  set  may  be  declared  as  having  a  possibly  unknown 
or  hidden  value.  For  example,  a  flashlight  battery's  charge  level  might  not  be  known  be 
direct  inspection  -  instead  a  test  meter  would  be  needed.  The  hideable  argument  allows 
MEBuilder  to  create  an  extra  property  set  which  contains  the  values  "<set>  is  known”  and 
"<set>  is  unknown".  This  information  is  available  for  use  during  task  construction  and 
lesson  construction.  In  addition,  if  a  property  set  is  declared  as  hideable,  the  teacher  may 
define  operations  whose  purpose  is  to  make  the  value  of  the  set  known  to  the  student. 

d.  reiation(<class>,  <relation  name>,  <definition>) 

Relations ,  or  "summary  facts"  allow  the  teacher  to  describe  a  substate  of  the 
object  in  a  single  term.  A  good  example  of  this  is  with  a  flashlight.  If  the  flashlight's  case 
is  closed,  top  is  assembled,  batteries  are  working,  and  bulb  is  working;  then  the  flashlight 
is  working.  When  METutor  prints  out  the  state,  the  four  members  of  the  definition  will  be 
replaced  with  the  single  phrase  "flashlight  is  working." 

e.  operation(<class>,  <indirect  objects> ,  operation  name>,  <intended 
effect>,  <preconditions>,  <side  effects>). 

Operation  facts  represent  the  primitive  operations  that  can  be  performed  on 
an  object.  By  "primitive",  this  refers  to  an  action  that  requires  one  turn  in  METutor  to 
complete.  The  indirect  object  list  is  a  list  of  all  other  objects  to  be  present  for  this  operation 
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to  be  available.  The  indirect  object  can  have  multiples,  including  another  <class>.  The 
operation's  name  is  an  imperative  sentence  -  a  verb  phrase  followed  by  a  direct  object 
followed  by  a  sequence  of  prepositional  phrases  if  needed.  The  direct  object  must  either 
the  <class>  or  a  valid  component  name  of  <class>. 

The  final  three  arguments  describe  the  behavious  resulting  from  this 
operation.  The  intended  effect  is  the  one  change  of  state  that  is  the  primary  reason  why  the 
student  would  perform  this  action.  For  example,  the  student  would  choose  "disassemble 
the  flashlight's  case"  for  the  intended  effect  of  "flashlight’s  case  is  open".  There  may  be 
other  changes  of  state  among  the  class  or  the  indirect  objects.  These  are  called  side  effects. 
The  precondition  list  is  a  list  that  describes  what  state  the  <class>  and  indirect  objects> 
must  be  in  before  the  operation  may  be  used. 

/.  daemon( <class>,  <daemon  name>,  <triggering  conditions 

<advancement  criterion:* ,  <advancement  form>,  <activation  message >) 
Daemon  facts  are  changes  of  state  that  occur  as  a  result  of  internal,  not 
external  stimuli.  Usually,  they  correspond  to  a  sequence  or  series  of  state  changes  which 
might  culminate  in  some  (possibly  disastrous)  event  at  the  end.  No  operation  is  performed 
to  effect  the  changes  induced  here,  instead  the  change  occurs  whenever  the  triggering 
condition  is  true  for  the  object.  The  activation  message  is  given  to  the  student  whenever 
the  triggering  condition  becomes  true.  The  advancement  form  describes  how  often  the 
change  in  state  occurs,  either  as  a  probability  of  change  or  as  the  number  of  turns  between 
changes. 

There  are  three  types  of  daemons.  The  progressive  daemon  causes  an 
object  to  take  on  the  first  value  of  some  property  set,  and  advances  until  the  last  is  reached 
or  the  triggering  condition  is  removed.  A  example  of  this  is  the  hunger  of  a  person.  At  the 
beginning,  the  person  may  be  full  --  but  later  he  progresses  through  peckish,  hungry, 
starving,  and  finally  dysfunctional  or  dead.  The  looping  daemon  loops  through  a  property 
set  The  streetlight  is  a  perfect  example  -  it  loops  among  green,  amber,  then  red,  then  back 
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to  green.  The  updating  daemon  invokes  an  operation.  Currently,  these  are  not 
implemented  -  but  they  are  intended  for  use  in  updating  readings  on  a  rneter  or  other 
continuous  functions. 

2.  Information  Cached  to  the  Other  Modules 

MEBuildCLS  does  not  send  the  class'  raw  data  to  the  other  modules  for 
processing.  Rather,  MEBuildCLS  will  receive  a  list  of  instantiations  from  the  other 
modules  and  will  return  instantiated  facts.  For  example,  a  lesson  has  a  "John  Smith"  who 
is  a  pilot.  The  pilot  object  has  a  property  set  of  "pilot  is  cleared  for  takeoff  and  "pilot  is 
not  cleared  for  takeoff.  MEBuildCLS  will  provide  an  instantiated  set  of  "John  Smith  is 
cleared  for  takeoff,"  etc. 

MEBuildCLS  only  sends  property  set  data  and  operation  data  to  the  task  module 
MEBuildTSK  and  the  lesson  module  MEBuildLES.  However,  all  class  information  is 
instantiated  and  sent  to  the  lesson  compiler  MEBuildCMP. 

E.  MEBLIILDER'S  TASK  DEFINITION  MODULE  -  "MEBuildTSK" 

MEBuildTSK  is  by  far  the  largest  and  most  complex  module  in  the  system.  It  serves 
the  purpose  of  developing  procedures  made  up  of  the  primitive  operations  of  its  member 
classes.  However,  its  underlying  purpose  is  simply  to  establish  relationships  among  the 
primitive  operations  within  specific  contexts  that  the  operations  themselves  do  not  convey. 

The  name  "task"  could  be  misleading.  When  the  teacher  builds  a  task,  he  describes  the 
entire  task  in  terms  of  a  known  starting  point  and  a  known  goal.  The  task  that  is  produced 
is  the  full  task.  However,  during  an  METutor  lesson  it  is  often  that  the  student  may  find 
himself  in  a  situation  that  puts  him  in  the  middle  of  the  task.  Here,  using  the  power  of 
means-ends  analysis,  the  student  can  still  complete  the  task  as  built 

The  key  to  successfully  building  a  task  is  providing  all  possible  solutions  to  the 
student  MEBuildTSK  uses  means-ends  analysis  to  help  find  alternate  solutions  and 
solutions  where  the  student  may  select  a  different  order  of  operations  that  will  still  achieve 


the  goal.  However,  it  is  far  better  to  keep  the  individual  task  as  small  as  possible  in  order 
to  ensure  consistency  when  put  together  with  other  tasks  in  a  lesson. 

The  task's  data  structure  is  made  up  of  several  components  —  basic  data  components, 
the  procedure  graph,  and  the  guaranteed  state  structure.  Not  all  elements  of  the  data 
structure  reside  in  secondary  storage  --  some  as  cached  by  MEBuildTSK  or  from  other 
modules  during  the  session  and  disappear  upon  completion  of  the  session.  Temporary 
facts,  however,  are  autosaved. 

1.  The  Task's  Basic  Data  Components 

The  following  is  in  addition  to  the  temporary  information  cached  from 
MEBuildCLS. 

a.  task(<task  name>,  <actor>,  <other  objects>) 

The  task  fact  indicates  those  objects  involved.  All  tasks  require  an  actor, 
which  is  an  object  descended  from  the  character  class.  The  other  objects  may  be  of  any 
class. 

b.  initial  condition s( <object>,  <state>)  and  objectives( <object>,  <state>) 
These  are  self-explanatory  in  nature,  however  the  respective  states  are  not 

absolute.  The  state  contains  one  entry  for  each  property  set,  but  the  entry  may  be  a  "don't 
care"  value.  "Don't  cares"  help  avoid  the  inclusion  of  unnecessary  operations  in  the  task 
and  provide  greater  flexibility  for  the  student. 

2.  The  Task's  Procedure  Graph 

Although  many  tasks  are  described  as  a  linear  sequence  of  steps,  few  tasks  are 
truly  linear  (Sacerdoti,  1990,  pp.  162).  Many  have  multiple  solutions  based  on  the  fact  that 
some  operations  can  be  done  in  different  orders.  Rules  such  as  the  preconditions  embedded 
in  the  objects'  operations  help  define  which  operations  must  precede  others.  However, 
those  preconditions  effectively  describe  the  behaviour  of  the  object  in  a  vacuum.  In  the 
context  of  a  particular  task  with  a  specific  goal  to  achieve,  new  rules  are  required. 
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Therefore,  a  structure  is  needed  that  describes  the  temporal  relationships  among  the  objects 
in  the  task. 

MEBuilder's  procedure  graph  is  based  on  Sacerdoti’s  Procedure  Net  (Sacerdoti, 
1990, pp.  163*168)  and  Homem de  Mello’s  and  Sanderson’s  assembly  state  graph  (Homem 
de  Mello,  1991,  pp.  229-231).  The  procedure  graph  is  built  based  on  a  first  attempt 
solution  to  the  problem  posed  by  the  initial  conditions  and  the  objectives.  MEBuildTSK 
then  assumes  that  its  solution  is  the  only  solution.  The  facilities  provided  by  MEBuildTSK 
then  allow  the  teacher  to  identify  alternate  solutions,  during  which  MEBuildTSK  checks  to 
ensure  they  are  indeed  valid  solutions. 

a.  Procedure  Graph  Structure  -  stages  and  actions 

A  procedure  graph  is  an  extended  directed  graph  where  the  node  is  called 
a  stage  and  the  transition  is  called  an  action.  A  sample  procedure  graph  is  in  Figure  4. 
Actions  contain  the  operation  to  be  performed  and  the  additional  preconditions  and  side 
effects  involved. 

Stages  are  conceptually  more  complex,  as  they  enforce  the  following  rules 
regarding  the  graph  structure.  First,  the  graph  has  one  start  state  and  one  done  state 
corresponding  to  the  initial  conditions  and  objectives  being  true.  Second,  a  stage  which  has 
one  transition  out  indicates  that  there  is  precisely  one  solution  to  achieving  the  next  stage. 
Third,  a  stage  which  has  more  than  one  transition  out  indicates  multiple  solr  ^ns  in  two 
forms  —  called  and-splits  and  or-splits.  An  and-split  indicates  that  the  transitions  out  of  the 
stage  correspond  to  subprocedures  that  can  be  done  in  parallel.  This  means  that  order 
among  the  actions  is  unimportant  so  long  as  actions  within  a  subprocedure  are  done  in 
order.  An  or-split  indicates  multiple  subprocedures  that  achieve  the  subgoal,  and  the 
student  only  must  perform  one  of  the  subprocedures.  Fourth,  all  splits  have  a 
corresponding  join  stage  (shown  in  Figure  4  as  the  shaded  stage  marked  with  a  "D  . 

Split-join  pairs  are  strictly  nested.  Therefore,  all  splits  are  joined  by  the 
time  the  done  stage  is  reached.  Join  stages  always  have  a  single  null,  or  lambda,  transition 


33 


out  The  extra  join  stage  is  required  because  a  split  stage,  such  as  Q1  in  Figure  4,  can  only 
have  one  split  On  the  other  hand,  Q5  could  close  multiple  splits.  This  could  only  be 
accomplished  through  the  use  of  a  sequence  of  nested  joins,  each  connected  by  a  lambda 
transition. 


Initial  Conditions  a  flashlight’s  case  is  dosed,  top  is  dosed,  batteries  are  dead,  bulb  is  broken 
Objectives  ■  flashlight's  csss  is  closed,  top  it  doted,  beticriee  tie  working,  bulb  it  working 


Figure  4:  Example  Procedure  Graph 


Procedure  graphs  may  also  have  unordered  actions.  These  are  actions 
which  are  required  to  be  performed  at  some  point  in  the  task,  but  have  a  very  loose  temporal 
relationship  with  the  other  actions  in  the  graph.  For  example,  a  given  device  may  need  to 
be  tested  before  use  during  a  task.  However,  one  might  not  care  when  or  where  the  device 
is  tested,  so  long  as  the  preconditions  for  the  testing  are  met  and  the  testing  is  done  before 
it  is  used.  These  are  similar  to  an  and-split  in  concept,  however  they  bypass  the  strict 
nesting. 


34 


b.  Options  for  Manipulating  Procedure  Graphs 

As  stated  earlier,  MEBuildTSK  starts  with  a  single  solution  and  assumes  it 
is  the  only  solution  -  so  the  student  must  follow  the  one  solution  in  order.  There  are  many 
ways  in  which  a  teacher  can  provide,  or  reduce,  the  number  of  solutions  available.  The 
fundamental  concept  MEBuildTSK  uses  is  dependency  of  the  primirive  operations.  An 
operation  X  is  dependent  on  another  operation  Y  if  and  only  if  X's  preconditions  are  not 
disjoint  with  Y's  postconditions.  After  the  teacher  performs  any  of  the  below, 
MEBuildTSK  invokes  means-ends  analysis  to  test  the  resulting  procedure  graph. 

A  teacher  may  request  MEBuildTSK  to  look  for  subprocedures  that  can  be 
parallelized.  These  are  found  by  examining  adjacent  actions  and  seeing  if  the  second  is 
dependent  on  the  first.  If  such  a  pair  is  found,  then  MEBuildTSK  looks  for  the  nearest 
operation  of  which  both  are  dependent,  then  follows  the  dependencies  to  identify  two  or 
more  possible  subprocedures.  This  process  produces  and-splits  in  the  procedure  graph.  A 
teacher  may  also  combine  subprocedures  together. 

A  teacher  may  ask  MEBuildTSK  to  declare  an  action  unordered  or  ordered. 
If  it  is  declared  unordered,  it  is  marked  as  such  when  the  user  asks  to  see  the  procedure 
structure.  If  an  action  is  declared  ordered,  it  is  placed  directly  in  front  of  the  action  that 
depends  on  it. 

A  teacher  may  move  individual  actions  around  within  the  bounds  of  the 
dependency  relationship.  He  may  reverse  two  actions,  move  an  action  intoa  subprocedure, 
or  move  it  out  of  a  subprocedure. 

Finally,  a  teacher  may  also  modify  the  preconditions  and  side  effects  of  an 
individual  action.  This  action  may  lead  to  MEBuildTSK  recalculating  the  solution  for  a 
task  or  the  subprocedure  the  action  is  in.  If  the  graph  no  longer  represents  a  valid  solution, 
MEBuildTSK  will  scrap  the  graph  and  start  over. 
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3.  The  Task's  Guaranteed  State  Structure 

The  guaranteed  state  database  parallels  the  procedure  graph  and  provides 
information  to  the  teacher  about  what  state  corresponds  to  the  completion  of  some  given 
step  at  any  point  in  time.  It  also  helps  identify  particular  contexts  in  which  an  operation 
will  behave  differently  than  as  primitively  defined.  The  latter  point  is  especially  true  when 
aprimirive  operation  is  specified  more  than  once  in  a  given  task  or  is  used  in  multiple  tasks 
within  the  same  lesson.  For  the  teacher,  this  structure  is  useful  primarily  for  information 
purposes.  He  may  request  to  see  the  anticipated  state  after  a  given  action  is  completed. 

The  guaranteed  state  is  a  single  state  for  all  objects  in  the  task.  There  is  one  entry 
for  all  property  sets  among  the  objects.  However,  each  entry  is  either  a  single  property 
which  is  absolutely  true,  or  is  a  list  of  properties  in  the  set  which  may  be  true  based  on 
probabilities  or  or-splits. 

F.  MEBUILDER’S  LESSON  DEFINITION  MODULE  -  "MEBuildLES" 

MEBuildLES,  by  contrast,  is  the  smallest  module.  MEBuilder  lessons  are  merely 
collections  of  individual  problems  which  the  student  can  try.  Every  lesson  must  have  at 
least  one  problem,  otherwise  the  lesson  is  meaningless.  MEBuildLES's  purpose  is  to 
provide  command  interfaces  to  the  lesson  data  structure  and  to  provide  access  to  the  lesson 
compiler  in  MEBuildCMP  and  the  underlying  METutor  system. 

The  lesson  definition  module  provides  both  the  lesson  loop  and  the  problem  loop,  as 
shown  in  Figure  3.  Each  manipulate  different  portions  of  the  MEBuilder  lesson. 

1.  The  MEBuilder  Lesson  Data  Structure 

MEBuilder  lessons  have  a  very  simple  data  structure.  The  lesson  fact  contains 
the  names  of  the  cast  members  by  name  and  type  (character  class),  the  props  by  name  and 
type,  and  the  tasks  involved  in  the  lesson.  The  lesson  Jniro  fact  contains  text  that  appears 
to  the  student  when  the  lesson  is  begun. 


2.  The  MEBuilder  Problem  Data  Structure 

MEBuilder  problems  are  numbered  in  order  starting  at  one,  and  each  problem 
has  its  own  of  the  following  data  items.  The  problem  fact  contains  the  name  of  the  problem 
and  those  cast  members  and  props  that  are  to  be  left  out  in  the  problem.  The  problemjntro 
serves  the  same  purpose  as  the  lesson_intro.  Each  problem  has  initial_setting  and 
objectives  facts  for  each  cast  member  and  prop,  which  correspond  very  closely  to  the  task's 
initial _condition  and  objectives  facts. 

Finally,  though  not  implemented,  hooks  have  been  placed  in  MEBuildLES 
where  a  teacher  will  be  allowed  to  override  some  of  the  probabilities  and  side  effects  among 
the  various  tasks.  These  overrides  will  allow  a  teacher  to  increase  the  level  of  difficulty  of 
some  problems  by  increasing  the  probabilities  of  some  bad  effects,  or  make  a  problem 
easier  by  eliminating  the  possibility  of  those  bad  effects. 

G.  MEBUILDER'S  LESSON  COMPILER  -  "MEBuildCMP" 

The  compiler  takes  a  lesson  which  its  associated  tasks  and  objects  and  produces  an 
METutor-ready  lessen.  The  compiler  only  works  for  METutor  versions  29  and  beyond. 
The  compiler  only  provides  a  single  command  to  the  user  —  that  of  "compile  lesson"  in  the 
lesson  loop.  The  overall  compilation  process  is  simple.  First,  final  integrity  checks  are 
performed  on  the  entire  class  hierarchy  for  all  classes  used,  followed  by  the  tasks,  a.id 
finally  the  lesson  itself.  Then,  each  METutor  fact  is  individually  constructed.  Some 
METutor  facts  are  required  to  be  cached  in  a  particular  order,  so  sorting  routines  are 
invoked  as  needed.  The  specific  content  of  die  METutor  database  and  how  they  are  derived 
from  compilation  is  given  in  the  next  chapter. 
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V.  TRANSLATING  AN  MEBUILDER  LESSON  TO  AN  METUTOR 

LESSON 

MEBuilder  and  METutor  shared  an  evolution  over  the  course  of  this  project.  As 
features  for  one  were  added,  so  too  was  the  ability  of  the  other  to  use  it  This  chapter  will 
present  METutor  version  29,  emphasizing  the  key  data  structures  and  philosophy  changes 
from  METutor  version  27,  the  last  active  version  before  this  project  It  will  then  present 
the  methodology  behind  how  MEBuildCMP  takes  lesson  material  in  object-oriented  form 
and  produces  an  METutor-usable  lesson  for  the  student 

Appendix  D  contains  sample  data  files  produced  from  MEBuilder  sessions.  Tab  1  is  a 
sample  library-directory  file  showing  the  library  entries  for  the  pilot  lesson  constructued  in 
Appendix  C.  Tabs  2  through  S  of  Appendix  D  contain  sample  MEBuilder  object,  task,  and 
lesson  files.  Tab  6  is  the  lesson  file  translated  to  METutor  form.  Appendix  E  contains  an 
excerpt  of  an  METutor  session  running  this  lesson. 

A.  HIGH-LEVEL  DESCRIPTION  OF  THE  DESIGN  CHANGES  IN  METUTOR 

1.  Workbook  Structure  Based  on  MEBuilder's  Lesson  Structure 

METutor's  original  interface  was  a  simple  one-level  interface,  and  METutor 
lessons  were  built  with  only  one  problem.  When  the  student  began  METutor,  it  presented 
the  single  problem  immediately  and  exited  once  the  student  completed  the  problem.  In  the 
new  METutor,  the  student  runs  a  main  command  loop  which  affords  him  options.  When 
the  student  selects  a  problem  to  do,  then  a  second  loop  is  engaged  which  runs  the  problem. 
A  student  can  exit  back  to  the  main  loop  at  any  time  and  retry  a  problem  if  he  so  desires. 

In  order  to  ensure  backward  comparability  with  lessons  written  before  the 
workbook  format,  METut"r  inspe  ‘  'oaded  lesson  files  for  structure.  If  the  lesson  file  does 
not  contain  a  workboo*  structure,  then  one  is  built  for  it. 
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2.  Agents  -  Based  on  MEBuilder  Characters 

An  agent  in  METutor  is  a  direct  manifestation  of  the  character  object  in 
MEBuilder.  The  goals  of  the  tasks  involving  character  objects  become  a  "resting  state"  for 
the  corresponding  agent  Each  agent  operates  using  his  own  set  of  means-ends  rules  based 
on  those  same  tasks.  Then  as  the  student  takes  his  turn,  all  the  other  characters  in  the 
problem  take  their  turn  via  this  agent  structure.  The  student  always  goes  first  in  a  given 
turn,  and  the  agents  follow  in  arbitrary  order. 


3.  METutor's  Macro-Expansion  Language 

The  most  visible  change  to  METutor  lessons  is  that  they  are  no  longer  a  set  of 
immediately  usable  Prolog  facts.  Rather,  they  are  most  macros.  It  is  in  the  use  of  macros 
that  MEBuilder's  object-oriented  philosophies  manifest  themselves.  The  introduction  of 
the  macro  form  was  based  on  lessons  which  had  multiple  objects  of  the  same  type  and 
potentially  rules  in  METutor  which  changes  from  problem  to  problem.  The  macro  form 
that  all  METutor  rules  use  follows  this  form: 


<rule-naiM>j(<agent>,  <quuntified  vars>,  <macro  argl>, ... ,  <macro  argn>) 

The  macro-indicating  entry  "_t"  is  stripped  off  and  the  quantified  variables  are 
replaced  with  concrete  ones  based  on  the  cast  and  props  in  the  problem.  For  example,  let's 
say  that  a  problem  has  two  flashlights  and  that  the  recommended  rule  dictates  that  to 
achieve  "flashlight  is  on"  one  must  "turn  on  the  flashlight".  Then,  the  macro  form  could  be 
described  as  follows.  The  quantified  vars  would  be  "for  each  flashlight  x".  The  first  macro 
arg,  corresponding  to  the  target  state,  would  be  "x  is  on"  and  the  second  macro  arg  would 
be  "turn  on  the  x".  If  we  named  the  two  flashlight's  in  the  problem  "red  flashlight"  and 
"silver  flashlight",  then  the  macro  expansion  would  insert  those  two  names  for  the  "x"  in 
the  above  phrases. 
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The  agent  argument  can  also  be  an  agent  domain.  For  example,  if  there  are  five 
agents  all  of  the  same  type,  then  the  object  type  name  fills  the  agent  argument.  Macro 
expansion  would  then  produce  five  sets  of  rules  —  one  for  each  agent 

If  there  is  only  one  of  a  given  object,  then  the  appropriate  macro  arguments  are 
pre-expanded  in  MEBuilder's  compilation  process.  This  is  because  macro  expansion  only 
gains  speed  and  space  when  there  are  multiples  in  the  object  domain.  Nothing  is  gained  in 
expansion  for  singular  instances.  Therefore,  the  actual  use  of  macro  expansion  in  the 
average  lesson  is  likely  to  be  small. 

4.  Backward  Comparability  of  Lesson  Material 

In  order  to  allow  backward  compatability,  METutor  version  29  wraps  a  general 
workbook  shell  around  the  lesson  database.  Also,  the  facts  arc  converted  to  macro  language 
format  This  backward  compatability  is  only  good  for  lessons  written  for  the  text-based 
versions  of  METutor  versions  1  though  27.  Lesson  material  for  MEGraph  versions  1 
through  27  will  still  work,  however  the  graphics  facts  are  ignored. 

B.  CONCEPT  OF  THE  TRANSLATION  PROCESS 

Much  of  the  translation  process  is  simply  copying  data  from  the  MEB wider  lesson 
layer  to  the  METutor  file.  Examples  of  this  include  the  introductory  text  for  the  lesson  and 
the  problems,  cast  and  prop  lists,  initial  settings,  goals,  and  identification  of  singular  and 
plural  nouns.  However,  the  means-ends  rules  --  consisting  of  the  recommended, 
precondition,  addpostcondition,  and  deletepostcondition  facts  along  with  the  random  event 
mechanism  called  randchange  —  are  more  complex.  All  five  of  these  are  generated  based 
on  the  usage  of  the  primitive  operations  in  the  tasks  loaded  in  the  lesson.  Some  of  these 
rules  must  also  be  sorted  so  that  the  higher  priority  operations  are  accessed  first.  Some  of 
these  rules  are  also  agent-specific,  meaning  that  they  apply  only  to  certain  characters  in  the 
lesson. 

The  translation  process  goes  as  follows.  First,  an  integrity  check  is  performed  on  all 
object,  task,  and  lesson  definitions.  Second,  the  workbook  data  (the  basic  lesson  and 
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problem  information)  is  cached,  which  includes  the  problem  start  states  and  goals.  Third, 
the  means-ends  facts  and  randchanges  are  constructed.  Finally,  the  singular,  plural,  and 
special  message  facts  are  placed  at  the  end.  Facts  that  are  agent-specific  are  cached 
alphabetically  by  agent  The  next  several  sections  describe  the  process  used  to  generate  the 
means-ends  facts  and  the  randchanges. 

C.  GENERATION  OF  THE  RECOMMENDED  CLAUSES 

The  recommended  clause  in  means-ends  takes  a  member  of  the  goal  that  is  not  true  in 
the  current  state  and  "recommends"  an  operator  to  achieve  the  goal.  This  is  the  exact 
purpose  that  the  intended  effect  provides  the  objects'  primitive  operations.  Therefore,  the 
recommended  clause  is  a  converse  map  from  an  intended  effect  to  its  primitive  operation. 

Recommended  clauses,  however,  are  among  those  that  must  be  sorted.  This  is 
because  METutors  means-ends  algorithm  gives  higher  priority  to  the  recommended 
clauses  at  the  top  of  the  Prolog  database.  This  is  how,  given  two  or  more  goal  members  not 
true  in  the  current  state,  METutor  determines  which  operation  is  the  best  given  the  current 
situation.  MEBuildCMP  uses  a  partial  ordering  scheme  to  determine  the  order  based  on 
the  following  rules: 

•  The  clause  recommending  operator  X  precedes  operator  Y  if  X  precedes  Y  in  a 
task. 

•  If  operators  X  or  Y  are  used  more  than  once  in  a  task,  then  the  ordering  is  based 
on  die  first  occurrence  of  the  operator  in  the  task. 

•  If  operators  X  and  Y  are  applied  in  reverse  order  among  multiple  tasks,  then  the 
ordering  is  arbitrary  and  will  be  based  on  the  other  operators  in  the  lesson. 

•  Operators  not  used  in  any  task  go  to  the  bottom  of  the  database. 

D.  GENERATION  OF  THE  PRECONDITION  CLAUSES 

The  precondition  clauses  are  more  complicated  than  the  recommended  clauses 
because  the  primitive  operation  can  have  preconditions  specified  from  four  difference 
sources.  These  sources  are  referred  to  by  type,  producing  Type  I  preconditions  through 


Type  IV.  If  an  operation  is  not  used  in  any  task  in  the  lesson,  then  only  Type  I  and  Type  II 
preconditions  apply.  If  an  operation  is  used  in  the  lesson,  then  all  four  preconditions  apply. 

•  A  Type  /  precondition  is  an  explicit  precondition  described  in  the  primitive 
operation. 

•  A  Type  II  precondition  is  an  implicit  precondition  of  the  primitive  operation.  It  is 
the  "opposite"  state  of  the  intended  effect.  This  is  a  precondition  because 
otherwise  the  operation  would  have  no  effect. 

•  A  Type  III  precondition  is  an  explicit  precondition  provided  in  the  task  definition. 
Rarely  will  any  operation  have  Type  III  preconditions. 

•  A  Type  IV  precondition  is  an  implicit  precondition  based  on  the  ordering  of 
actions  a  task.  The  intended  effect  of  the  previous  action  becomes  a  precondition 
of  the  operation.  Often  the  Type  II  and  Type  IV  preconditions  will  be  the  same. 

In  addition,  preconditions  may  be  subject  to  context.  This  only  applies  if  one 
operation  is  used  more  than  once  within  the  same  task.  The  context  helps  determine  which 
application  of  the  operation  corresponds  to  which  precondition  clause.  The  context  is 
determined  by  taking  the  guaranteed  state  in  which  each  occurrence  of  the  operation  exists 
and  comparing  them.  Those  items  in  the  state  that  are  guaranteed  to  differ  become  the 
context  A  null  context  argument  means  that  the  clause  applies  to  all  applications  of  the 
operation. 

Precondition  clauses  are  also  sorted  items.  The  sorting  is  based  on  the  desire  to  access 
the  most  restrictive  precondition  clause  first.  Restrictiveness  in  this  sense  is  defined  as  the 
number  of  elements  in  the  context  argument.  Longer  contexts  are  placed  first.  Null 
contexts  are  placed  last. 

E.  GENERATION  OF  THE  POSTCONDITION  CLAUSES  # 

The  addpostcondition  and  delete  postcondition  information  come  from  two  sources 
-  the  objects'  primitive  operations  (Type  I)  and  the  task  operations  (Type  II).  The 
postconditions  from  the  primitive  operations  consist  of  the  intended  effect  pits  the  side 
effects.  The  postconditions  from  the  task  are  the  definite  side  effects  only.  Probabilistic 
side  effects  are  treated  differently  because  their  effect  is  not  guaranteed.  Once  the 


postconditions  have  been  collected,  they  make  up  the  addpostcondition  information  and  the 
opposite  of  each  addpostcondidon  member  makes  up  the  deletepostcondidon. 

Because  operations  may  be  used  more  than  once  in  a  task  and  therefore  may  carry 
different  side  effects,  these  clauses  also  have  context  arguments.  However,  the  context 
argument  is  only  non-emtpy  for  those  operations  with  task-defined  side  effects.  In  addition, 
if  the  task-defined  side  effects  are  identical  for  all  uses  of  the  primitive  operation,  then  the 
postconditions  are  merged  together  with  a  null  context 

Postcondition  clauses  are  sorted  in  the  same  manner  as  precondition  clauses.  The 
longer  context  arguments  go  to  the  top  of  the  database  and  are  accessed  first. 

F.  GENERATION  OF  THE  RANDCHANGE  CLAUSES 

The  randchange  or  random-event  clauses  come  in  many  different  forms.  For  this 
reason,  randchanges  are  also  given  Type  designations. 

•  A  Type  I  random-event  is  based  on  uncertainty  among  members  of  the  initial 
setting.  The  teacher  specified  these  in  turns  of  percentages  when  listing  responses 
to  the  "condition  is  probabilistic"  sequence  of  questions. 

•  A  Type  II  random-event  is  based  on  the  probabilistic  side  effects  given  in  the  task. 
These  random-events  are  operation-triggered. 

•  A  Type  III  random-event  is  based  on  object  daemons.  Type  Ilia  use  probabilities. 
Type  Hlb  use  counts  to  advance.  Type  lllb  random-events  might  sound  less 
random  then  their  probabilistic  counterpart.  However,  since  these  daemon-based 
events  are  condition  triggered,  the  advancing  event  is  not  guaranteed  to  occur. 
Hence,MEBuildcr  treats  them  like  a  random  event. 


Randchange  facts  consist  of  the  following  information,  and  are  agent-independent. 
The  first  item  is  the  triggering  action  -  for  Type  I  it  is  init,  for  Type  n  it  is  the  operation 
name,  for  Type  III,  it  is  any_op  to  represent  "any  operation".  The  second  is  the  context, 
which  is  calculated  the  same  way  as  with  precondition  clauses.  Context  arguments  are  only 
non-null  in  a  Type  n  randchange.  The  next  two  arguments  are  the  postconditions  -  delete 
and  add.  The  fifth  argument  is  the  probability  of  occurrence  or  the  countdown  to 
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occurrence,  discussed  further  below.  Finally,  the  sixth  argument  is  the  message  which  is 
printed  to  the  user  when  the  random-event  occurs.  The  message  for  a  Type  I  is  blank. 

Type  mb  randchanges,  based  on  a  countdown  to  next  occurrence,  introduce 
information  to  the  state  which  is  hidden  from  the  user.  METutor  will  maintain  a  special 
state  member  which  contains  the  randchange's  postconditions,  message,  and  countdown 
value.  The  student  is  not  informed  that  the  countdown  is  active.  After  each  student  turn, 
METutor  will  decrement  the  counter.  Once  the  countdown  reaches  zero,  the  postconditions 
are  activated  and  message  passed  to  the  student.  Countdowns  are  the  first  random-event 
handled  after  the  student's  action. 
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VI.  EXPERIMENTAL  RESULTS 


During  the  Summer  Quarter  of  Academic  Year  1994,  an  experiment  was  conducted  to 
demonstrate  that  MEBuilder's  method  of  lesson  authoring  was  more  robust  and  less  time 
consuming  than  authoring  a  lesson  in  a  traditional  Computer-Aided  Instruction  (CAI)  form. 
Appendix  F  contains  all  the  information  disseminated  and  gathered  during  the  experiment. 

A.  PARTICIPATION  IN  THE  EXPERIMENT 

The  experiment  included  six  students,  hereafter  referred  to  as  the  "participants"  taking 
the  Advanced  Artificial  Intelligence  class  at  the  Naval  Postgraduate  School  All  six  have 
taken  an  introductory  artificial  intelligence  class  during  the  spring  quarter.  The  students 
had  never  used  METutor  before.  As  part  of  the  advanced  course  content,  the  participants 
received  some  basic  instruction  about  CAI  methods  and  introductions  to  intelligent  tutoring 
systems. 

The  participants  are  American  military  officers.  None  had  ever  authored  a  lesson  for 
an  intelligent-tutoring  system.  All  have  experience  as  military  trainers,  but  most  have  little 
or  no  teaching  background.  Therefore,  the  experiment  will  not  target  how  well  MEBuilder 
works  in  an  actual  educational  setting.  Rather,  it  will  focus  on  MEBuilder's  ability  to 
outperform  CAI  in  terms  of  simple  lesson  construction  -  does  the  task  of  building  a  lesson 
take  less  time,  is  it  more  complete,  and  does  it  produce  fewer  errors? 

B.  SCOPE  AND  CONDUCT  OF  THE  EXPERIMENT 

I.  The  Participants  and  Their  Requirements 

Tab  1  of  Appendix  F  contains  the  detailed  instructions  given  to  the  students.  The 
participants  were  divided  into  two  groups,  but  each  participant  was  to  work  individually. 
The  first  group  of  four  participants  was  tasked  to  write  a  lesson  for  a  scuba  diver  preparing 
to  dive  for  lobster  (see  Tab  2,  Appendix  F).  The  second  group  of  two  participants  was  to 
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write  a  lesson  for  replacing  a  gasket  in  a  car  engine's  water  pump  (Tab  3,  Appendix  F).  The 
reason  for  the  imbalance  is  because  two  participants  had  to  withdraw  from  the  experiment 
and  there  was  insufficient  time  to  realign  the  groups.  The  two  tasks  were  selected  and 
modified  such  that: 

•  Both  tasks  required  14<15  steps,  so  the  amount  of  work  is  similar  among  the  two 
groups. 

•  Both  tasks  have  36  possible  solutions. 

•  Both  tasks  were  originally  written  for  METutor  versions  21-27  and  are  ideal  tasks 
for  a  CAI-based  tutoring  system. 

The  participants  were  provided  with  access  to  MEBuilder  and  METutor,  along 
with  CAIBuilder  and  CAITutor  —  a  lesson  authoring  system  built  with  CAI  methods  and  a 
CAI-based  tutoring  system.  CAIBuilder  is  written  on  top  of  CAITutor  in  the  same  manner 
as  the  MEBuilder  system  in  order  to  duplicate  the  authoring-to-shell  environment.  Finally, 
the  participants  were  given  access  to  automated  measurement  tools  which  helped  collect 
some  of  the  required  data.  Tab  4  of  Appendix  F  describes  how  the  participants  were  to  use 
the  automated  tools. 

In  order  to  provide  as  fair  a  comparison  as  possible  between  the  two  methods, 
several  restrictions  had  to  be  placed  on  use  of  MEBuilder  -  specifically  those  features 
which  the  CAI  method  clearly  has  no  equivalent.  For  example,  the  lesson  was  to  be  written 
using  one  and  only  one  task.  This  is  because  CAIBuilder  does  not  have  a  mechanism  of 
combining  tasks  into  a  single  task.  Second,  the  students  were  only  to  build  one  problem  in 
the  lesson  workbook  frame  as  part  of  the  experiment.  CAI  has  no  equivalent  to  MEBuilder's 
workbook  frame.  The  features  of  MEBuilder  not  tested  in  this  experiment  will  be  tested  in 
future.  Third,  the  order  of  use  between  the  CAI  method  and  MEBuilder  was  mixed  -  four 
students  used  the  CAI  method  first,  two  used  MEBuilder  first.  Again,  the  imbalance  was 
due  to  the  withdrawals. 

Finally,  there  was  a  six-hour  ceiling  on  the  experiment.  Any  participant  reaching 
six  hours  was  to  stop  and  turn  in  the  partial  results.  This  was  due  to  time  constraints  on  the 
availability  of  the  participants.  In  order  to  help  meet  the  time  constraint  and  still  adequately 
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test  the  task-manipuiation  processes  of  both  methods,  the  students  were  provided  with 
partial  solutions.  These  partial  solutions,  given  in  Tabs  5  and  6  of  Appendix  F,  contained 
a  task  structure  of  one  complete  solution  with  no  options. 

2.  The  Data  to  be  Collected 

The  information  the  students  were  required  to  gather  included  time  spent  using 
each  method,  number  of  operations  using  each  method,  and  some  statistical  measurements 
on  the  resulting  data  structures.  They  also  had  to  answer  some  questions  regarding  how 
their  time  was  spent  using  the  CA1  and  MEBuilder  methods.  Even  though  some  of  these 
measurements  arc  numeric,  they  were  not  intended  to  be  interpreted  as  significant  raw  data. 
Instead,  as  described  below,  these  measurements  were  to  be  interpreted  subjectively  as  a 
means  of  identifying  trends.  With  the  exception  of  time,  all  the  precise  measurements  were 
done  through  automated  means,  as  described  in  the  following  sections. 

a.  Time  Measurements 

There  were  two  measurements  requested  —  the  amount  of  lime  spent  on  the 
CAIBuilder  and  MEBuilder  programs,  and  a  subjective  breakdown  of  how  the  time  was 
spent  The  time  is  to  be  given  in  hours,  and  is  not  intended  to  be  a  precise  measurement. 
Rather,  it  is  a  subjective  measurement  to  see  if  one  method  was  significantly  quicker  than 
the  other.  The  two  tasks  were  written  in  such  a  way  that  if  done  properly  the  students 
should  spend  roughly  an  equivalent  amount  of  time  on  each  solution.  The  students  were 
specifically  instructed  not  to  include  down  time  due  to  program  bugs. 

For  the  second  part,  the  students  had  to  rank  the  amount  of  time  spent  in  the 
following  four  processes:  familiarizing  with  the  program,  designing  the  data,  entering  the 
data,  and  testing  and  using  the  data.  These  were  given  for  CAIBuilder  and  MEBuilder  as 
a  whole,  and  then  asked  separately  for  the  class,  task,  and  lesson  layers  within  MEBuilder. 
Familiarization  encompassed  reading  the  user's  manuals  and  running  the  samples  given 
inside.  Designing  the  data  meant  organizing  the  data  on  paper  prior  to  running  the 
authoring  system.  Entering  the  data  encompassed  time  spent  using  the  adding  commands 
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to  get  the  data  into  the  system.  Testing  the  data  encompassed  checking,  debugging,  and 
modifying  the  data  once  it  was  in  the  system. 

The  expected  trends  were  that  CAIBuilder  users  would  identify  entering 
and  testing  as  two  most  time-consuming  processes.  MEBuilder  users,  on  the  other  hand, 
would  identify  familiarization  and  design  at  all  layers  with  the  possible  exception  of 
entering  at  the  object  layer.  These  would  indicate  that  MEBuilder  has  a  steeper  learning 
curve.  However,  if  the  time  spent  on  MEBuilder  was  less,  then  that  means  the  productivity 
using  MEBuilder  is  significantly  greater. 

b.  Operations  Measurements 

CAIBuilder  and  MEBuilder  were  embedded  with  a  counting  mechanism  in 
order  to  determine  how  many  commands  were  used  in  each  system  and  trie  percentage  of 
commands  aborted.  An  aborted  command  is  a  command  that  failed  or  a  command  whose 
subsequent  queries  were  explicitly  aborted  by  a  participant.  In  addition,  MEBuilder's 
commands  were  broken  down  by  layer.  These  help  support  the  time  measurements  above 
by  identifying  interface  problems  as  a  possible  factor.  If  a  command  is  confusing  or  a 
participant  doesn't  understand  what  the  queries  mean,  he  will  tend  to  abort  the  command. 
On  the  other  hand,  if  a  particular  layer  was  identified  as  time  consuming  in  the  entering  and 
testing  processes  and  it  had  few  aborted  commands,  that  would  signal  that  the  layer's 
interface  is  inefficient. 

c.  Examining  the  Data  Structures 

Examining  the  resulting  data  structures  would  provide  indicators  about  the 
probable  correctness  of  the  resulting  tasks  and  how  robust  the  task  is.  Since  the  operator 
names  were  not  strictly  standardized,  an  automated  examination  of  the  content  of  the 
structures  is  not  feasible.  However,  the  number  of  acyclic  paths  to  the  solution  can  be 
measured  efficiently.  If  the  participant's  tasks  are  in  accordance  with  the  lesson 
specifications  given,  his  lessons  will  have  36  solutions.  Because  CAI  methodology  puts  the 
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burden  on  the  participant  to  construct  the  paths,  it  was  anticipated  that  the  CAI  solution 
counts  would  vary  more  than  the  MEBuilder  solution  counts. 

"Robustness"  is  in  term  of  the  number  of  nodes  and  transitions  needed  in 
the  respective  data  structures.  Since  MEBuilder  relies  on  METutor  for  coaching  rules, 
MEBuilder  users  do  not  have  to  add  information  about  student  errors  into  the  task.  If  the 
student  fails  to  follow  the  correct  sequence,  then  METutor  will  handle  the  error.  This 
means  that  the  number  of  nodes  and  transitions  needed  by  MEBuilder  are  minimal  ~  a 
maximum  of  one  transition  and  one  node  per  operation. 

However,  CAlBuilder  users  must  add  explicit  error  states  and  transitions. 
For  each  transition  along  a  solution  path,  the  lesson  should  provide  two  or  three  wrong 
answers  to  afford  the  student  a  choice.  In  addition,  each  wrong  answer  transition  requires 
a  path  back  to  the  solution.  A  non-robust  method  would  have  only  a  single  error  state  and 
single  transition  back  to  the  start.  A  good  method  would  have  a  single  error  state  per  error 
transition.  So  a  fully  robust  CAlBuilder  solution  should  have  roughly  three  times  the  nodes 
and  six  times  the  transitions  that  the  MEBuilder  solution  might  have.  Combined  with  the 
time  and  operation  measurements,  this  would  help  describe  how  much  better  MEBuilder 
could  do  with  a  much  more  complicated  task. 

3.  The  Deliverables 

In  addition  to  the  above  data,  the  participants  were  required  to  provide  a  short 
write-up  of  their  work.  The  write-up  was  to  include  comments  and  opinions  regarding  the 
experiment  and  the  MEBuilder  program.  Attached  to  the  write-up  is  the  resulting  data  files 
produced  by  the  two  authoring  systems,  along  with  script  files  showing  the  lesson  being 
used  in  the  corresponding  tutoring  shells.  The  evaluation  of  the  experiment  focused  on  the 
write-up,  specifically  if  it  included  comments  about  the  interface  and  problems 
encountered  not  adequately  identified  elsewhere. 
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C.  RESULTS  OF  THE  EXPERIMENT 

Appendix  F  contains  the  raw  data  generated  by  the  data  collection  programs  on  all  six 
participants.  The  data  collection  program  outputs  are  in  Tab  7  and  selected  comments  from 
the  participants  are  in  Tab  8. 

1.  Time  Measurements 

Hie  participants  took  roughly  the  same  amount  of  time  to  do  the  task  on  either 
system,  with  the  CAI  system  requiring  slightly  more  time.  The  minimum  time  spent  on 
CAIBuilder  was  one  hour  (by  one  participant),  the  maximum  was  three  hours  (by  three 
participants),  and  the  average  was  2.5  hours.  For  MEBuilder,  the  minimum  was  one  hour 
(by  two  participants),  the  maximum  was  three  hours  (by  one  participant),  and  the  average 
was  2.0  hours.  Four  of  the  six  required  less  time  to  complete  the  requirements  in 
MEBuilder.  Only  one  required  more  time  with  MEBuilder,  and  the  sixth  spent  an  equal 
amount  of  time  with  each  system.  In  both  systems,  familiarization  with  the  program  and 
entering  the  data  were  cited  as  the  most  time  consuming  processes,  although  MEDuilder 
showed  a  greater  distribution  of  time  usage  than  CAIBuilder. 

2.  Operations  Measurements 

The  participants  required  from  68  to  164  commands  to  complete  the  task  in 
CAIBuilder,  with  an  average  of  123.  With  MEBuilder,  however,  the  range  was  only  1 1  to 
45  with  an  average  of  26.  In  terms  of  completed  commands  (total  commands  minus 
aborted  commands),  CAIBuilder  users  required  an  average  of  121  while  MEBuilder  users 
averaged  15.  The  minimum  number  of  commands  needed  to  complete  the  requirement  in 
CAIBuilder  was  30,  so  CAIBuilder  users  completed  four  times  the  necessary  commands. 
With  MEBuilder,  the  minimum  number  of  commands  needed  was  ten,  so  the  participants 
performed  1.5  times  the  necessary  commands  in  MEBuilder. 

Participants  aborted  MEBuilder  commands  nine  times  more  often  than 
CAIBuilder  commands.  In  CAIBuilder,  two  participants  completed  the  requirements 
without  having  to  abort  any  commands.  The  highest  percentage  of  aborted  commands  in 
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CADBuilder  was  6.5%  and  the  average  was  just  above  2%.  In  MEBuilder,  however,  only 
one  participant  performed  no  aborts  and  two  participants  had  to  abort  more  than  30%  of 
thier  commands.  The  average  rate  for  the  participants  was  18%. 

It  is  important  to  note  that  the  data-coUection  program  failed  with  one  participant 
and  the  MEBuilder  command  usage  was  lost  The  participant  stated  that  his  command 
usage  was  not  significantly  different  from  the  norm. 

3.  Resulting  Data  Structure  Measurements 
The  data  structures  produced  all  MEBuilder  sessions  were  identical  to  the 

solutions  produced  by  the  author.  The  CADBuilder  solutions,  however,  differed.  All 
participants  stopped  at  the  point  where  the  CAI  task  was  complete,  without  adding  error 
conditions  or  states.  The  four  diver-problem  participants  did  achieve  the  author's  solution 
of  23  nodes  and  32  transitions.  However,  those  doing  the  cooling-system  problem  did  not 
match  the  author's  resulting  data  structure  nor  did  they  achieve  36  solutions  to  the  task. 

4.  Comments  from  the  Participants 

The  positive  comments  focused  on  one  primary  theme.  Both  systems  were 
deemed  simple  enough  to  use  once  one  gets  accustomed  to  them.  Neither  system  was  so 
difficult  to  use  that  they  felt  unable  to  complete  the  task.  In  addition,  once  the  participants 
became  accustomed  to  MEBuilder  they  found  MEBuilder  quicker  and  more  flexible. 

The  vast  majority  of  the  negative  comments  collected  centered  on  two  major 
themes.  The  most  common  concerned  the  user  interface.  Both  CAIBuilder  and  MEBuilder 
use  a  somewhat  crude  command-line  interface  that  wasn’t  friendly  and  had  errors.  Most 
participants  agreed  that  die  help  facility  was  weak.  Comments  specifically  directed  at 
MEBuilder  was  that  the  sequence  of  steps  in  the  "create  lesson"  command  were  confusing. 

The  second  theme  was  that  once  a  particular  part  of  the  requirements  were 
complete,  it  was  not  readily  apparant  what  to  do  next.  For  example,  once  a  participant 
finished  with  a  task,  some  did  not  understand  that  the  next  step  was  to  construct  the  lesson. 
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D.  INTERPRETATION  OF  THE  RESULTS 

The  results  show  that  using  MEBuilder’s  task-manipulation  method  produced 
consistent  and  correct  results  more  quickly  than  the  CAI  method.  Despite  the  fact  that  none 
of  the  participants  added  student-error  transitions  to  the  task,  they  still  required  more  time 
to  complete  the  task  manipulation  than  with  MEBuilder.  In  addition,  CAIBuilder  users 
performed  significantly  more  commands  than  required  due  to  navigation  and  editing.  This 
is  a  clear  indication  that  MEBuilder’ s  method  is  more  efficient. 

Further,  had  the  students  been  required  to  work  with  a  more  complex  problem  the 
results  would  more  heavily  favor  MEBuilder.  To  illustrate,  consider  the  original  lessons 
from  which  the  tasks  used  in  the  experiment  were  derived.  The  original  cooling-system 
problem  (McDowell,  1993)  was  18  steps  long  but  had  720  solutions,  not  counting  the 
unordered  actions.  The  original  scuba-diver  problem  (Seem,  1992),  not  counting 
unordered  actions,  had  22  steps  and  36  solutions. 

The  CAI  data  structure  for  the  original  cooling-system  problem  would  have  required 
1080  transitions  to  model  the  solutions  alone.  Since  the  CAI  method  works  via  one 
transition  per  command,  the  rate  of  command  usage  would  likely  have  changed  little. 
Therefore,  by  extrapolating  the  time  and  command  usage,  CAIBuilder  users  would  require 
20  hours  to  build  the  extended  task.  One  could  not  expect  a  teacher  to  do  so  and  produce 
an  error-free  lesson.  On  the  other  hand,  because  MEBuilder  allows  single  commands  to 
perform  significant  modifications  to  a  structure,  users  could  create  the  720  solution  in 
minutes  with  only  a  few  commands. 

With  its  two  unordered  actions,  the  number  of  solutions  to  the  coollrg-system  problem 
increases  to  69,192.  MEBuilder  only  requires  one  command  to  declare  an  unordered 
action,  so  only  two  commands  are  needed  to  achieve  this  increased  complexity.  Clearly, 
CAIBuilder  users  would  not  be  reasonable  capable  of  producing  an  equivalent  lesson.  The 
original  scuba-diver  problem  had  three  unordered  actions  and  4,320  solutions. 
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E.  CONCLUSIONS 

This  experiment  proves  MEBuilder’s  concept  that  an  authoring  system  using 
intelligent  rules  can  produce  lesson  material  much  more  efficiently  than  traditional  CA1.  In 
addition,  the  resulting  MEBuilder  lesson  requires  far  less  code  space  and  can  be  modified 
significantly  faster  than  with  a  traditional  CAI  method. 

This  experiment  also  shows  that  for  MEBuilder  to  be  effective,  the  user  interface  is 
extremely  important  Such  an  interface  should  assist  a  teacher  in  entering  commands  to  the 
terminal  through  the  use  of  menus  and  structured  dialogs.  It  should  also  provide  a  means 
of  helping  the  teacher  understand  the  authoring  process,  and  provide  a  good  help  facility 
for  the  teacher  to  fall  back  on. 

The  experiment  also  showed  that  move  work  is  needed  in  the  lesson-definition  system. 
The  interface  needs  to  make  the  overall  process  more  intuitive.  An  appropriate  follow-on 
experiment  would  have  the  participants  given  a  set  of  tasks  and  by  required  to  construct 
different  types  of  lessons.  The  lessons  would  contain  problems  that  range  in  difficulty  from 
beginner-level  to  expert-level.  The  levels  of  difficulty  could  be  achieved  by  breaking  the 
task  into  components  or  adding  random  hazards  to  the  problem. 
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VII.  CONCLUSIONS  AND  FUTURE  RESEARCH  DIRECTIONS 

A  SUMMARY  OF  CONTRIBUTIONS 

MEBuilder's  object-oriented  design  and  teacher-assistance  tools  show  great  promise  in 
the  construction  of  a  general-purpose  lesson  authoring  system.  Its  library-management 
features  help  organize  lesson  information  and  hide  the  low-level  file  structure  from  the 
teacher.  Its  object-modelling  techniques  help  ensure  consistency  and  reduce  errors  when 
building  tasks.  Its  task-modelling  techniques  help  build  complex  yet  robust  procedures  in 
a  manner  of  minutes.  Its  workbook- style  lesson  framework  help  a  teacher  construct  a 
multitude  of  exercises  to  serve  a  wide  variety  of  purposes  -  from  increasing  levels  of 
difficulty  to  presenting  different  subtasks. 

The  experimental  results  suppons  MEBuilder’s  concept  and  design  as  having 
tremendous  potential.  It  showed  that  MEBuilder  could  be  a  more  effective  and  efficient 
authoring  system  than  one  based  on  traditional  CAI  methods.  Further,  MEBuilder 
produces  lessons  with  a  higher  degree  of  assurance  and  a  lower  risk  of  error.  Also,  because 
of  MEBuilder,  METutor  has  evolved  to  handle  a  greater  range  of  problems.  These 
problems  include  those  involving  other  characters,  multiples  of  like  props,  and  multiple 
exercises  in  a  lesson. 

B.  WEAKNESSES  OF  MEBUILDER 

MEBuilder  is  not  without  problems,  especially  given  that  it  is  a  project  in  its  genesis. 
There  are  several  areas  which  require  significant  adjustments  and  improvements  before  this 
program  can  be  considered  releasable. 

1.  Is  Object-Modeling  Too  Complex  For  Teachers? 

MEBuilder  is  heavily  reliant  on  object-oriented  modeling  techniques,  which 
may  be  beyond  the  comprehension  of  many  computer-illiterate  educators.  Currently,  the 
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object-definition  module  is  very  unhelpful  in  its  presentation.  A  teacher  might  not 
understand  what  it  means  to  inherit  property  sets  or  operations.  Part-kind  inheritance  is  an 
extremely  difficult  concept  even  for  most  students  of  artificial  intelligence.  MEBuilder 
requires  additional  features  that  help  visualize  the  object  as  it  is  being  defined,  and  help  the 
teacher  understand  the  implications  of  modifying  object  inheritance.  In  addition,  future 
experiments  should  be  conducted  using  professional  educators  outside  the  realm  of 
computer  science.  Military  trainers  would  be  a  good  example. 

2.  Lack  of  P re- Defined  Object  Library 

In  order  for  MEBuilder  to  be  effective,  it  must  come  with  an  extensive  library  of 
pre-defined  objects  and  tasks.  Otherwise,  a  great  number  of  lessons  will  consist  of  objects 
that  are  only  good  for  that  lesson  or  whose  behaviour  has  been  limited  to  meet  the  needs  of 
only  one  lesson.  In  addition,  the  object  layer  is  where  the  greatest  amount  of  time  is  spent, 
and  the  desire  is  for  the  teacher  to  devote  energy  mostly  at  the  lesson  layer.  Object  re-use 
is  a  major  selling  point  in  object-oriented  modeling,  and  only  with  an  extensive  and 
accurate  library  of  objects  can  this  benefit  be  realized. 

3.  MEBuilder  and  METutor  Do  Not  Employ  the  Same  Domain  of  Features 

There  are  features  built  into  METutor  which  MEBuilder  presently  does  not 

access.  This  includes  a  wider  domain  for  summary-fact  definitions,  multiple  goals,  and 
other  quantifier  expressions  within  the  macro  languange  templates.  The  converse  is  also 
true.  The  macro  language  does  not  perfectly  handle  class  inheritance  of  objects,  so  a 
problem  written  for  a  prop  of  some  object  might  not  work  exactly  right  for  objects  of  a 
derived  class.  A  lot  more  work  is  required  to  ensure  that  the  features  of  MEBuilder  and 
METutor  are  brought  to  a  perfect  one-to-one  correspondence. 

4.  Emphasis  Needed  on  the  Interface 

The  initial  focus  on  MEBuilder  has  been  on  its  architecture,  algorithms,  and  data 
structures.  However,  as  shown  in  the  experiment,  MEBuilder  requires  a  strong  user- 
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interface  in  order  to  be  effective.  The  user 'interface  needs  to  provide  easier  command 
access,  simple  and  understandable  representations  of  all  MEBuilder  entities,  and  a 
thorough  and  context-sensitive  help  facility.  A  graphical  interface  using  menus  and 
windows  would  be  ideal. 

C.  FUTURE  RESEARCH  DIRECTIONS  FOR  MEBUILDER  AND  METUTOR 

1.  Coaching  Capabilities 

The  scope  of  both  programs  only  extends  to  the  conduct  of  exercises  and  some 
basic  tutoring  rules  based  on  means-ends  algorithms.  In  order  to  help  make  the  resulting 
lesson  more  believable  to  the  student,  both  programs  require  means  of  specifying  and 
implementing  domain-specific  coaching  rules.  These  are  rules  which  can  evaluate  a  full 
sequence  of  student  actions  and  help  find  possible  cognitive  errors  that  a  means-ends  based 
error  will  not  detect. 

2.  Including  Ancillary  Domains  in  MEBuilder 

Some  entities  cannot  be  modeled  adequately  as  a  property  set,  but  can  be 
modelled  using  summary  information.  An  example  of  this  is  an  audit  file  for  an  operations 
system,  which  contains  a  list  of  the  operations  performed  by  users  in  a  computer  center 
simulation.  The  entries  of  an  audit  file  constitute  the  file's  state,  however  one  certainly 
cannot  efficiently  model  these  entries  beforehand  in  a  property  set  nor  use  the  raw  data  in 
means-ends  analysis.  Summary  information  based  on  audit  file,  on  the  other  hand,  can  be 
used  in  means-ends. 

An  audit  file  is  an  example  of  an  ancillary  domain.  The  term  "ancillary"  is 
appropriate  because  it  supplements  die  state  with  raw  data.  The  extension  of  MEBuilder 
(and  therefore  METutor)  to  cover  ancillary  domains  must  handle  three  areas  -  the 
definition  of  the  ancillary  domain  and  the  associated  summary  facts,  the  definition  of 
operations  that  impact  the  ancillary  domain,  and  the  relationship  of  the  ancillary  domain  in 
the  task  and  lesson  structure.  Other  important  but  less  critical  issues  include  the  display  of 
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ancillary  data.  The  qualitative  state  methodology  of  METutor  lends  itself  to  a  simple 
output  interface.  Ancillary  domains  would  require  a  more  complex  interface. 

3.  Including  Quantitative  Domains  and  A*  Search  Techniques  in  MEBuilder 

MEBuilder  is  still  limited  to  qualitative  problems  that  only  view  the  state  as  a  list 

of  objects'  current  properties.  Many  applications  have  quantitative  values  involved,  such 
as  reading  on  a  boiler  or  an  operation  such  as  "turn  dial  to  X".  The  current  object  layer  in 
MEBuilder  can  be  extended  to  handle  different  domains,  including  quantitative  ones,  along 
with  associated  operations. 

In  addition,  the  means-ends  algorithm  in  METutor  uses  the  ordering  of  facts  in 
the  database  to  break  ties  among  sets  of  operations  that  can  be  performed  at  a  given  step. 
The  ordering  of  facts  may  be  inappropriate  or  incorrect  given  some  contexts.  In  addition, 
this  method  only  helps  answer  die  question  of  what  to  do,  but  not  how  much  to  do  it.  In 
older  to  adequately  apply  quantitative  operations  in  a  given  problem,  die  means-ends 
algorithms  in  both  programs  require  supplementation  with  a  quantitative  search  method. 
A*  is  suggested  here  because  it  is  the  most  general  purpose  search  method  available  and  it 
is  built  to  address  the  specific  issue  of  solving  a  procedural  task  in  the  least  costly  manner 
(whether  in  terms  of  time,  resources,  etc.).  A*  as  a  basis  for  an  intelligent  tutoring  system 
has  been  explored  separately  (Galvin,  1994,  p.  725). 

4.  Use  of  MEBuilder  in  a  Major  Application 

Currently,  MEBuilder  has  only  been  tested  in  the  context  of  simple  applications. 
The  next  set  of  tests  involving  MEBuilder  must  demonstrate  its  ability  to  handle  complex 
simulations  with  many  different  agents.  An  example  of  such  an  application  might  be  a 
tutoring  system  for  a  system  administrator  learning  computer  security.  In  such  an 
application,  legitimate  users  and  intruders  would  serve  as  agents  in  a  simulated 
environment  and  the  student  would  be  charged  with  maintaining  the  system.  Such  an 
application  would  take  full  advantage  of  MEBuilder's  object-oriented  modeling  and  would 
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be  sufficiently  complex  to  test  MEBuilder's  simulation  capabilities.  It  would  also  help 
uncover  bugs  that  simpler  applications  do  not  produce. 

5.  Using  MEBuilder  with  Other  Intelligent  Tutoring  Systems 

Currently,  METutor  is  the  only  intelligent-tutoring  system  with  which 
MEBuilder  will  work.  In  addition,  MEBuilder  uses  many  of  the  same  algorithms  as 
METutor  during  automated  task  generation.  This  allows  MEBuilder  to  guarantee  that  its 
lesson  will  work  in  METutor.  However,  MEBuilder’s  value  would  be  greatly  increased  if 
it  could  generate  lessons  for  other  established  intelligent-tutoring  systems,  such  as  PIXIE 
(Sleeman,  1987,  p.  239).  To  accomplish  this,  MEBuilder  requires  user-selectable  Lesson 
Compilers,  one  for  each  supported  intelligent-tutoring  system. 
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APPENDIX  A.  MEBUELDER  SOURCE  FILES 

i  i  ■  ; 

This  appendix  only  contains  the  header  comments  for  the  primary  MEBui-der  source 
files  and  the  primary  METutor  version  29  source  file.  This  is  for  practical  considerations 
given  that  the  source  is  nearly  400  pages  long  and  contains  more  than  one  megabyte  of  text. 

Only  those  source  files  directly  relevant  to  MEBuilder’s  primary  functions  are 
included.  Files  not  included  are  the  help  system  source  files,  several  Prolog  utility  files 
written  by  the  author,  and  the  supplemental  data  collection  module  used  for  the  experiment. 
Also,  the  author  has  deleted  segments  of  the  header  comments  from  the  below  files  which 
describe  future  upgrade  requirements 


Tab'l.  mebuitd.pl  --  MEBuilder’s  Main  Module 

Tab  2.  mebuild_class_definition.pl  --  MEBuildCLS  module  source 

Tab  3.  mebuild_task_definition.pl  —  MEBuildTSK  module  sou.ee 

Tab  4.  mebuild_lesson_definition.pl  --  MEBuildLES  module  source 

Tab  5.  mebuild_lesson_compiier.pl  --  MEBuildCMF  module  source 

Tab  6.  mebutid_library.pl  -  MEBuildLIB  module  source 

Tab  7.  metutor29_shell.pl— METutor  version  29  source 
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TAB  1.  MEBUILDER  MAIN  MODULE 

. . 

/*  Meena-Bnds  Unn  Building  Program  --  Vara' on  1  (MBBUXbDIR)  */ 
/*  CPT  Ii«au  J.  Oelvin,  D.f.  Any,  Naval  Poetgraduete  school,  Monterey  CA  93940  */ 
/a*...**..*....**...*..*.*******..........*.... ......................... .a*......../ 

/•  MBOXLDXX  Main  Interface  —  Version  1  */ 
/•  */ 
/*  To  run  MKBuilder.  load  ‘this*  nodule  and  query  i  */ 
/•  */ 
/•  r-  build,  •/ 
/*  */ 
/*  SOTS i  Vo  run  MtSulldar  with  tha  currant  Prolog  databaaa  intact ,  query:  */ 
/.  */ 
/*  i-  build_without_initiali*ing.  */ 
/•  •/ 
/*  The  letter  la  designed  for  uaa  aa  a  raeevary  tool  should  MKBuilder  perform  */ 
/*  a  lasa-thaa-graoaful  exit  during  axaoution.  */ 
/*  «/ 
/*  Tha  nain  interface  nodule  provides  tha  conssand  loop  and  aeeeaa  to  the  */ 
/*  subordinate  Interface  nodules.  It  also  nanagae  tha  autosave  file  —  which  is  */ 
/*  a  local  file  duep  of  all  dynamically  created  nodules  and  tha  help  facility  */ 
/*  —  which  is  a  simple  evb-oaamand  loop  providing  somewhat  context  sensitive  */ 
/*  help  to  the  user.  Access  functions  to  the  subordinate  data  etructuras  are  */ 
/'provided  through  the  following  facts i  */ 
/*  *7 
/*  logal_ocnnand(<cnnnenr1>, .predicate.) .  */ 
/‘  •/ 
/*  .command,  ie  the  input  retrieved  from  text_io'e  gat _proopted_ input .  Tha  */ 
/*  predicate  ie  a  taro -argument  predicate  which  perform#  tha  analegoue  eonmand.  */ 
/*  legal_ccnmend  is  a  Multifile  fact,  but  ie  'not*  dynamic.  */ 
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TAB  2.  MEBUILDER  CLASS  MODULE  (MEBuildCLS) 

/••*••**•**•*•*•*******»»•*•******•***••***•*•**••**•»•»•*•****•*****••**********"/ 
/•  Maans-Bnda  Miicb  Building  Program  —  Vara ion  1  (MBBUILS1R)  */ 

/*  CBT  Thoama  P .  Oaivin,  U.l.  Army,  Naval  Postgraduate  Bohool,  MoaCaray  CA  93940  */ 
/eaeveeeeeeeeeeeeeeeee.eeo ......e**...,,**.... 

/*  MBBOZLSn  claaa  Definition  Nodula  --  Varaion  1.01  •/ 

/*  •/ 

/•  Varaion  Nlaeozy  */ 

/*  1.0  --  Firat  ralaaaa.  conoant r at aa  on  o resonant,  proparty  aat>  and  */ 

/*  oparation  daflnleioaa.  Tbs  relations  and  daanona  ara  daflnad  and  •/ 

/*  iaelndad  tout  tbair  of facta  ara  far  Iron  guarantaad  to  work  in  a  */ 

/*  eoapilad  laaaon.  •/ 

/*  1.01  —  Cooaaanta  ara  updatad  and  stub.  plaoad  for  n<— anda  or  pradieataa  */ 

/*  aaadad  for  usa  In  fntura.  Tba  proparty_diaplay_data  and  tba  •/ 

/*  oparatlan_diaplay_data  aaotiona,  which  wara  not  naad  in  tba  */ 

/*  compiler,  ara  stubbed  out.  (Thaaa  abould  ba  fixed  bafora  X  go).  */ 

/*  •/ 

/*  Important  Compilation  Not at  »/ 

/*  During  tba  Quintus  Prolog  linking  proeaaa,  tba  following  two  pradieataa  ara  */ 
/*  amouncad  aa  unknown.  Vhia  ia  eauaad  by  canpiling  and  linking  the  program  */ 
/*  in  tba  Prolog,  not  tba  Prow  Iadova  environment!  */ 

/a  uaar iprowindowa/0  */ 

/*  uaartdraw_proparty_pictura/0  »/ 

/*  uaantbd/M  (for  any  H  —  uaad  to  idantify  coda  atuba)  */ 

/*  If  and  whan  tba  HMbuild-Claaa_daf inition_graphlce  fn*  ia  permanently  in-  */ 
/•  otallad  into  NEBuildar,  tbaaa  naaaagaa  will  go.  away.  •/ 

/*  •/ 

/*  •/ 

. . . . . . / 

/*  XDuildar'a  Claaa  definition  data  atruetura  */ 

/*  •/ 

/■*  A  claaa  ia  dafinad  aa  tba  eoNposite  of  tba  following  facta  with  tba  same  •/ 
/*  <olaar>  argument  aa  tba  firat  argument.  */ 

/.  •  / 

/•  elaea_def  (<olaaa>,  diet  of  parent  classes*) .  V 

/*  NOT*  on  <parent  claaaaa>.  The  atandard  parent  claaaaa  of  prop  and  •/ 

/*  character  ara  uaad  to  indicate  tba  apacif lc  type  of  object  it  ia  and  */ 

/*  what  oapabilitiaa  it  baa.  Character  ebjacta  have  tbo  additional  cap-  */ 

/*  abilitlaa  of  being  tba  primary  actor  of  a  taak,  and  can  ba  lmatantiated  */ 

/•  aa  tbo  atudant'a  role  in  a  laaaon.  Currently  only  aingla  inheritance  */ 

/*  la  eupported  by  HBBu.lldor,  however  the  inheritance  faeilitiaa  provide  */ 

/*  for  expansion  into  aailtipla  Inheritance.  •/ 

/*  */ 

/*  cowponent ( <Claaa> ,  ecaaponant  claaa  bnm>,  <ccmponant  na— > ,  <tanaa>) .  */ 

/*  NOT*  on  ocaponantai  Tana  a  ia  given  aa  a  insular,  plural,  or  default  and  */ 

/*  la  uaad  to  override  tba  "and*  in  a"  rule  whan  determining  plural  wwp*  */ 

/ 1  ia  the  atandard  Xngl lab- language  output.  */ 

/*  */ 

/*  prcperty_eet(<olaee>,  eproparty  eat  aama>,  <domain> ,  <hideabl«>) .  */ 

/*  where  .hidaable*  it.  hi da ah la  |  not_bidaabla  »/ 

/*  .hide  able*  corraaponda  to  tba  eraation  of  hideabla  facta  in  tbo  NSTutor  */ 

/*  laaaon.  A  preparty  aat  that  la  hidaable  automatically  ganarataa  bolaa  •/ 

/*  ter  tba  opacification  of  operators  that  handle  hidaable  facta.  »/ 

/*  NOT*  on  preperty.setsi  Peat  lsplementationa  of  MSBulldsr  used  tba  aama  */ 

/*  atruetura  for  moo  bora  of  a  preparty  aat  aa  for  tba  KITutor  facta  uaad  */ 

/*  a  means -anda  search  apace.  Thin  varaion  uaad  only  the  prefix,  which  */ 

/*  ia  intended  to  eliminate  the  waataful  operand  replacement.  */ 

/*  */ 
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P**pm*ty_4isplay_d*ta(<cla*s>,<property>,<graphice  dat*>) .  ‘I 

tot  version  1.01,  *11  interfacing  with  prop*rty_dlsplay_data  ha*  been  */ 
dalatad  and  stubbed  out.  The  »ebuild_elasa_def inition_grapMc»  fila  */ 
costal**  tba  capability  tot  specifying  a  graphic  for  tha  proparty.  Tba  V 
^graphics  data>  would  costal*  only  tboaa  thing*  that  ara  ganarieally  */ 
trua,  aueb  aa  tha  graphlo  bitmap  fila  and  tba  dimension*.  Ml  otbar  */ 
details,  aueb  aa  tha  color,  location,  click  rang*,  ate.  ara  part  of  tba  •/ 
individual,  laaacn  definition  (rafar  to  laaaon  definition  fila.  */ 

*/ 

relation <« a la* e>,  <objeot>,  <proparty»,  <dafinition  aat  of  properties*).  */ 
X  relation  ia  a  nata-proparty  which  ia  true  if  tha  <dafinition  aat  of  •/ 

propertlaa  ia  nat.  «objact>  ia  cither  <cla*a>  or  a  valid  component,  */ 

and  comprises  tba  atata  argunant  to  <proparty>.  <proparty>  ia  a  symbol  •/ 
and  < definition  eet>  ia  of  tha  fern  atonic  —  eorraaponding  to  a  */ 

property  of  tha  olaaa,  or  of  tha  fora  <prcparty> ( tcomponant* )  for  tboaa  */ 
prepartiaa  bald  for  tha  ocaponant.  */ 

V 

daemon (<class>,<daemon  name* ,  triggering  condi t ion* >, <advaneement  cond>,  */ 
^advance  typa>,  <naaaaga  template*!.  */ 

where  triggering  conditioner  are  condition*  that  eauaa  the  daemon  to  */ 
"wake  up"  or  "atay  awaka".  Tba  da  anon  ia  checked  at  each  turn  whan  the  */ 
triggering  conditioner  are  trua.  Whan  a  daemon  ia  activated,  it  i*  V 
doctrinally  aat  to  tha  firat  ■ caber  of  the  iterating  property  aat,  */ 

although  in  maatia-enda  apace  it  can  in  theory  start  at  any  place.  */ 

< advancement  condr  ara  apaelal  conditions  that  indicate  chat  tha  daemon  */ 
will  wake  up  —  either  prob(<probability>)  or  count (< integer r)  where  •/ 
integer  corresponds  to  the  number  of  turns.  Tha  < advance  typer  cor*  V 
eaponda  to  one  of  two  thing*  --  either  advance ( <proparty  set  of  class*)  •/ 
’which  indicates  that  the  daemon  will  always  advance  to  the  next  */ 

property  in  the  eet,  loop(<property  set  of  elaesr)  which  the  same  aa  */ 
advance  except  that  the  object's  value  can  revert  to  the  first  value,  */ 
or  update (<operation*)  where  <operation>  i*  a  defined  operation  of  the  */ 
class  Vhioh  takas  *no*  indirect  objects,  (This  1*  probably  an  unneaded  */ 
restriction  which  could  be  cured  ia  future.  •/ 

The  message  teaplete  is  uaad  Whan  the  daemon  becomes  active,  lisa,  */ 

tha  massages  used  to  describe  the  daemon's  advancement  (ell  in  line  •/ 

with  the  property  set  members  and  tba  separation* '#  apply  text.  •/ 

*/ 

operation (solace*,  sob j act  llstr,  <verbr,  <direot  obj.r,  <trail  phraser,  */ 
^precondition  liatr,  <iatended  affectr,  <eids  effect  liatr>.  */ 
MOTSt  Tha  4-tuple  (sobjact  llstr  <varbr  <dlract  obj.r  strell  phraaar)  */ 
is  considered  as  e  whole  to  be  the  identifying  name  of  an  op.  */ 
operation  modela  specifically  one  type  of  method  —  tha  atomic  method.  •/ 
operation  facta  describe  an  atomic  operation  --  one  that  takas  one  */ 
agent -turn  to  perform  and  cannot  be  broken  down  further,  operations  */ 
era  not  character  Independent  —  they  can  be  overloaded  by  specifying  */ 
tha  highest  level  character  class  as  aa  objaot.  If  no  character  class  */ 
is  specified,  than  there  is  an  Implicit  a* sumption  that  all  character  */ 
classes  can  perform  tha  operation.  •/ 

sclase*  la  eoasidarad  tha  direct  object's  class.  < object  list>  is  a  */ 
complete  Hat  of  objects  that  ara  required  to  be  present  la  order  to  */ 
perform  the  operation.  Mote  that  class  can  be  repeated  —  meaning  that  */ 
an  operation  must  take  two  or  more  distinct  object*  of  the  seme  claas.  */ 
There  will  exist  e  means  to  specify  forall  in  operations  however  such  */ 
capability  ie  not  yet  present.  •/ 

The  <verb>  is  e  verb  phrase.  <dlreet  ctoj.»  is  either  seises*  or  a  */ 

valid  ocmponeat  of  sclase*.  strell  phrase*  can  be  any  combination  of  */ 
words,  however  any  subsequence  of  word*  which  match  a  member  of  •/ 

<object  list*  will  be  funetored  with  cbj()  In  order  to  do  inheritance  * / 

an  tha  name  of  tha  operation,  ^precondition  list*  matches  on#-f or-li*t  •/ 
with  respect  to  [sclase* I sobjeot  list*].  < intended  effect*  ie  a  single  */ 
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property  which  will  boeeaw  true  upon  application  of  this  operation  and 
auet  be  a  defined  property  of  < direct  obj.>. 

eper4tioa_diepXay_data(<ola>a>,  <operation>,  <diaplay  data>) . 

Wot  version  1.01,  all  oper at ion_diaplay_data  itaaa  have  been  deleted  or 
stubbed  out.  The  only  useful  thing  for  < display  data>  would  be  the 
generic  or  default  tent  string  used  to  generate  an  apply_text  in  a 
lesson.  < display  data>  could  be  expanded  to  include  animation  data 
for  showing  as  operation  occurring.  This  is  not  used  as  a  9th  arg  to 
the  operation  fact  because  the  hierarchy  of  display  it ess  does  not 
necessarily  follow  that  of  the  preconditions  and  postconditions. 


Classas  ara  modeled  using  Quintus  Prolog  dynamically-created  Modules ,  so 
the  facte  for  a  class  c  is  C:elaes_def <C,PCL)  -  Ciooaponent (c.cc.cw)  -  etc. 
This  allows  this  aodula  to  taks  advantage  of  tha  nodula  feature  in  taxt_io's 
prolog_out fils  predicate. 

Classes  ars  not  directly  accessed  by  outside  nodules.  ceche_clees_facte 
is  used  to  take  ell  the  elees  information  end  oaehe  it  into  date  retrievable 
by  the  lesaon  database. 


*/ 

•/ 

•/ 

V 

V 
•/ 

V 
•/ 
*/ 
•/ 
•/ 
*/ 
*/ 
•/ 
•/ 
•/ 
•/ 
*/ 
*/ 
•/ 

V 


Cc— ends  provided  by  this  nodule  (including  those  not  yet  implemented) 
Docnueentatlon  on  these  coanands  can  be  found  in  tha  user's  manual. 


•/ 

*/ 

*/ 

*/ 

*/ 

V 

*/ 

*/ 

*/ 

*/ 

•/ 

*/ 

•/ 

•/ 

•/ 

•/ 

•/ 


•/ 

•/ 

*/ 

*/ 

*/ 

•/ 

•/ 

V 

*/ 

•/ 

*/ 

•/ 

*/ 

*/ 

*/ 

*/ 

•/ 

*/ 

*/ 

•/ 


0BJ1CT  DKPZHZTIOM  COMMANDS: 

create  object  (named  <obj#et») 
remove  object  (named  <object>] 
restore  object  [named  <object>] 
view  abject  (named  <objeot>] 
modify  parent  object  (of  <cbject>] 
cheok  object  (named  <objeot>] 

CCMPOHUIT  MAUAOIMXMT  COMMANDS: 

create  aesponent  (named  <cocponent>)  [for  <object>] 
remove  covenant  (named  < component >]  [from  <cbject>] 
view  component  [named  <cooponent>)  [of  <ebject>} 
modify  component  (named  <ccmponant>)  (of  «objeet>) 


HOPIATY  SIT  MAMAOSMkMT  COMMANDS  t 

craata  property  eat  [named  ^property  sat>]  [for  «object>) 
remove  property  set  [named  <property  eet»]  [from  <object>] 
view  property  set  [named  ^property  set>]  [of  <objeet>] 
modify  property  set  (named  <property  set>)  (of  «objaet>] 
set  property  display  data  (for  <property> ]  [of  <objaet>] 


SUMMARY  TACT  MAMAaSONT  COMMANDS: 
create  summary  fact  [for  <object>] 
remove  susaary  fact  [from  <abject>) 
view  saury  fact  [of  <objaot>] 
modify  oummaxy  fact  [of  <ebjaet>] 

operation  MMHwmnn  commands: 
oreata  operation  (for  <object>) 
remova  operation  [frea  <objsct>] 
view  operation  (of  <objact>) 
modify  operation  [of  <object>] 
set  operation  display  data  (of  <obj*et>] 

BACXmODND  CHAMOE  MAMAOEMEMT  COMMANDS: 


LOOPS: 

Main 

Main 

Main 

All 

Main 

All 


Main 

Main 

All 

Main 


Main 

Main 

All 

Main 

Main 


Main 

Main 

All 

Main 


Main 

Main 

All 


Main 
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create  btakgrouad  a  bang*  [suwS  <daanon>]  {for  <objvot»l 
rwsv>  background  change  [nsaad  <da*aon>]  [fro*  <objsct>] 
view  background  change  (naaed  <daaaon>]  [of  < objects] 
Modify  background  change  [naaed  <daeaon>]  [of  <objsct>) 


Exported  predicatee.  All  predicates  Intended  for  external  use  are  prefixed 
with  *mabuildCLE_” 


APPLICATION  PREDICATED  (All  exported  to  aebuild  main)  i 
mebuildCLE.setup . 

—  Initialises  all  the  domains,  coeeeande,  and  tenple.te*  for  the  nain 
mabuild  application  naaaenl  loop. 

«ebuildCLg_include_vlew_cr—  ends  (♦Loop) 

—  Provides  Loop  with  the  class  definition  view  ccamaods  so  use  in 
the  task  definition  and  lesson  dsfinition  loops. 
*ebuildCLS_clsss_database_initialise . 

Initialises  the  class.def initios  database. 
mabuildCULclass_databe»e_shutdnwn. 

Clears  all  olas#_detinitioa  facts  froa  the  Prolog  database  and  erases 
all  dyaaaically-araated  nodules,  read  by  KkBuild's  guit  comaand. 
MbuildCUl_append_autosave . 

Appends  all  class  definition  date  in  semory  tc  the  eutoeave  tile. 

CLASS  DEFINITION  MANMEKENTt 
(COMMAND  INVOKED) 
nabuildCLS_daf  iiu_cl#ss  (»cla*  » ) . 

Provides  user  access  ter  defining  a  sew  class. 
nabuildCLS_rse»ve„claes(+llasf ) . 

Marks  a  class  ae  “deleted"  (refer  to  library  sodule) . 
nebuildCI>S_restore_alaea UGlass) . 

kestores  a  removed  class  in  awns cry  (i.s.  undeletes  it). 
mabaildCLS_vlew„clase t+Class) . 

Pretty-print  s  the  clasw  definition  to  ths  screen.  Only  provider  a  by¬ 
name  listing  of  ths  class  nssdars .  Pot  nors  detailed  information  a- 
bout  a  particular  data  Itts.  rafar  to  the  corresponding  view  cossaand 
below. 

mabulldCMLmoaiCy_clees  i  +Clats) . 

Allows  the  user  to  ahanga  the  parent  olass  link. 

(COMMAND  INVOKED  AND  EXPORTED  TO  OTHER  NODDLSS) 
MbulldCLS_tast_class_lntegrlty  ( tclass ) . 

Allows  the  usar  to  tast  tba  integrity  of  the  class  to  ensure  the  class 
definition  le  consistent.  The  test  includes  checking  whether  or  not ■ 
--  Vil  referenced  ccnponente,  properties,  and  operation*  in  tha 
are  still  well-defined. 

--  That  changes  to  tha  we) 1-  defined  nanbars  of  ths  class  does  not 
cause  other  seebate  of  the  claee  to  beccaM  contradictory. 

The  saoartics  of  the  particular  taste  are  given  is,  the  predicates  in 
each  segment  named  <objsct>_violat*s_int#grity. 

(EXPORTED  TO  OTHER  NODDLES) 

mebulldCLN_oaehe..taak_taees(+TaryetNodule,*Li*t  of  Xnstanee/class  pairs) 
Produces  cached  versions  of  ths  class  dsfinition  for  uss  in  ths  tssk 
modules.  Only  ths  property  sets  and  tha  operations  are  cached  for 
use  in  task  definitions . 

msbuildCL»_cache_leeson_f acts  UTsrgatModula, ♦List  of  Xnataace/Claes  pairs) 
Produces  cached  versions  of  the  class  definition  during  coopilaticn. 
mobuildCLfl_export_olasses (+List  of  Claes /Pile  pairs) 

Panda  out  tha  class  definitions  in  nanory  to  the  files  listed. 
mebull4CLa_dariv*d_olest_pf ( +cla»s , r Descendant ) 

Teats  for  derived  olass  relationships  or  provides  a  darived  class. 
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/*  — bttlMCIJLl«_«jreB_oXw  (♦Claaa  >  */ 
/•  *ebuildCI>8_i»_a_chaxactar_clas0  ( ♦class)  */ 
/*  Ipacific  instances  of  nsbuildCLS_darivad_class_o£  for  the  generic  •/ 
/*  "prop"  ud  "character"  objects.  */ 
/•  V 
/•  CCMPOMMMT  SStXMZTXJX  NUUBRIfft  */ 
/•  {COMOKD  ZMVOKKD)  */ 
/*  mabulldCL»_def lna_ocapaDant  ( ♦Component ,  ♦Clasa ) .  */ 
/*  Trovidaa  war  access  to  tha  covenant  definition  facility.  The  •/ 
/*  Crayon  ant  auat  be  uni  qua  to  Claaa.  Tha  uaar  will  ba  prompted  aapaz-  */ 
/*  ataly  for  a  Component  claaa  with  which  the  cceyonont  will  ba  an  In*  */ 
/•  atanoe  of,  and  It  will  aatabliah  a  part_of  inharitanca  ralationahip.  */ 
/*  Circular  part_of  lhharitaaea  la  not  allowed  and  Crayon antHama  auat  ba  */ 
/*  unique.  */ 
/*  mebuliaCLS_ramove_ccmponsnt  ( ♦Ccsyonent ,  aClaa » ) .  •/ 
/*  Dndaflnaa  tha  eoayonaht  from  tha  claaa.  Tha  component  auat  ba  a  */ 
/*  defined  ooaponant  of  tha  claaa,  not  an  inherited  one.  •/ 
/*  a»bulldCLa_viaw_oowponant ( ♦Component , ♦Claaa ) .  •/ 
/•  Piaploys  the  entire  covenant  definition  in  pretty-printed  fern  —  */ 
/*  Including  tha  eource  of  tha  component  definition  (whether  defined  in  */ 
/*  tha  object,  inherited  fron  a  parent  object,  or  inherited  iron  a  */ 
/*  component  object.  */ 
/*  nabuildCL8_iaodify_coaponont (♦Component, ♦claaa) .  */ 
/*  Allow*  tha  uaar  to  nodify  any  of  tha  attributes  associated  with  tha  */ 
/•  ccsyonent  definition  —  type,  naaa,  or  tense.  Tha  eonponant  auat  ba  •/ 
/*  a  defined  ooaponant  of  tha  class,  not  an  inherited  one.  */ 
/•  (RXPOATXD  TO  OTBR  M0DDU8)  */ 
/•  nabulldCL8_flat_aingular_ooaponapt (♦Class, -BingularCoaponant) .  «/ 
/*  aebuildCLS_gat_plural_coaponant  ( ♦claaa ,  -P  luralCoyonant ) .  *  / 
/*  Retrieves  a  coaponant  definition  of  tha  Class  which  overrides  tha  */ 
/•  tense  default  (singular  and  plural,  respectively) .  */ 
7*  •/ 

/*  PI0PSRTY  SIT  SZPXMXTXON  KAKAORMXHT i  */ 
/•  (COMMAND  INVOKED)  */ 
/*  mabuildCb8_def  las_preperty_aet  i  ♦FropertySet ,  ♦Claaa ) .  *  / 
/"  Provides  user  aocasa  to  tha  property  sat  definition  facility.  Tha  •/ 
/*  Property  Sat  nan*  mat  ba  unique  to  the  class.  Tha  user  will  ba  V 
/*  queried  tor  a  list  of  property  eat  aaabers  (currently  only  lists  of  */ 
/*  syabels  are  allowable) ,  and  if  tha  Sut  is  hideable  (meaning  that  tha  •/ 
/*  sat  represents  a  fact  in  tha  world  which  could  ba  unknown,  •/ 
/*  Tha  members  of  List  of  Properties  auat  ba  unique  for  a  claaa,  to  */ 
/*  include  class  hierarchical  links,  unleaa  tha  Property  sat  ia  rede fin-  */ 
/*  leg  an  inherited  property  sat.  Object  hierarchical  links  do  not  */ 
/*  require  this  restriction.  */ 
/•  nabuildCLS_rea0ve_property_set(4Property8at, ♦Class) .  *t 
/*  Dndaflnaa  tha  property  sat  and  undatinas  all  of  tha  nanber  proparty  */ 
/*  data.  Xt  does  not  automatically  unde  fine  all  of  tha  oparators  and  V 
/*  relations,  etc.  (that  is  extremely  eonplex  and  it  ia  basically  left  V 
/*  for  tha  teacher  to  manage  using  tha  integrity  checker) .  Tha  property  */ 
/•  sat  must  ba  a  defined  member  of  tha  object,  not  an  inherited  ana.  V 
/ *  mabuildCLf _view_prcperty_aat ( ♦propertySet .♦Class) .  * / 
/*  Prints  out  a  datailad  definition  of  tha  property  eat,  including  whore  */ 
/*  it  la  defined  from  (cither  in  tha  object  itself,  inherited  from  a  •/ 
/*  parent  or  ancestor,  or  inherited  from  a  ooaponant).  */ 
/*  nabuildCU_nodify_property_aet  (♦FropartySeti  ♦Claaa)  •  */ 
/*  Allows  tha  uaar  to  modify  tha  property  set,  either  its  name,  members,  V 
/*  or  its  bide ability  declaration,  tha  Property  eat  given  auat  ba  a  */ 
/*  defined  property  sat  of  tha  object,  not  an  inharltad  one.  •/ 
/*  (SXPORTKS  TO  ffln  WOSCUM)  •/ 
/*  aabulldCLS_gat_hldeabls_propsrty_aat  (♦claaa ,  -Propartytat ,  -Domain) .  */ 
/*  Locates  and  returns  a  hi  da  able  property  eat  for  the  oonpilor.  */ 
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aebui  ldCLr_adJ  acent_properties  ( +Cla»« ,  +Prepertyset ,  loop  lno_locp, 

TPropertyl, ? Property 2) . 

for  property  uti  intended  to  bo  iatozprotod  »•  o  sequence  of  state* , 
this  function  serves  oa  o  successor  and  prodocoaaor  function  which  is 
capable  of  returning  ell  peira  if  the  leat  two  ere  unbound.  Thia 
function  ia  atrictly  non-trenaitiva.  The  loop  narker  in  the  third 
argunent  indicetea  that  the  firet  nanber  of  the  aet  ia  considered  the 
successor  of  the  lest. 

print_current_property ( +Obj eat ,  +»ec  t  > -Output ) . 

Takes  the  abject  end  feet  end  esssnbles  e  list  of  words  output  which 
with  prlnt_neun  can  be  outputted,  print _eurrent_propsrtr  is  intended 
for  use  with  print.list  as  a  teaplate. 
asssnble_propertles(40bjeet>«PropertyDoatain> -hssenbledProperties) . 
neasanbla_prepertiea (eObjaet, +PropertyDcaaln, -AssenbledPropertles) . 
yasaaable_praperties (^Object, *PropertyDo*u»in, -AaseabledPropsrtlea) . 
aaseable_property ( +Qbjact , + Property, -AsseabledProparty) . 
xasseabla_property (eObject , +Property, -AsaeabledProperty) . 
yessenble_property (eobjeet , eProperty, -AsseabledProparty) . 

These  ere  used  to  put  together  and  disasseable  properties  to  and  from 
their  cbjeat  end  basic  property  eenponents.  Their  differences  are  as 
follows  > 

plain  m  only  for  objects  with  their  defined  properties, 
x  m  for  assenbling  objects  with  thsir  defined  or  component 

properties 

y  e  for  assenbling  tesplatea  of  properties  (especially  for  the 

laseon  eeapller) 

oppoeite_of (eObjeet, ^Property, ^opposite) . 
negation_of (eobjeet , ePreperty, ♦(legation) . 
list_cpposite_of (eObject, ePropertias, eOppositee) . 
list_negat ion_of  ( ♦Object ,  epropert las ,  ellegat ions ) . 

Oppositas  and  negations  ere  two  cenoepts  that  are  aljailar.  For  a  eat 
of  one  or  two  aaebers,  they  are  the  wane.  For  threae,  however,  the 
negation  of  a  property  X  le  aisply  not (X) .  The  opposite  of  property  X 
in  desaain  oneof  ( (X,T1, . . .  ,Tn) )  is  Yl,  then  Yd,  ....  Y». 

The  list  versions  return  begofe  all  possible  answers  and  returns  it  in 
a  singls-leval  list. 

build_ordinal_dual_arglist (eobjacts, -Fairsof Xnstance/Ob  jests) . 

Ordinal  dual  arglists  are  used  to  specify  an  abstract  set  of  instances 
for  uee  in  oleea  definitions  and  tasks.  Xt  takes  e  list  of  objects 
and  attaches  ordinal  nones  to  repeated  instances  of  the  objects, 
lx.  le.b,c,s,b,e]  beecnas  {a,b,e, ( (second, a), a), (second, h], (third, a)] 

PAOPIKTY  DISPLAY  DATA  MAXAOBBHT  i 
(COMtAMD  XMVOXBD) 

nsbulldCLS_aat_property_display_data ( ^Property , ♦clas j ) . 

Invokes  the  property  display  data  nanegsaant  subccsnand  loop.  This  is 
mostly  stubbed  out,  but  does  contain  books  to  access  thu  graphics 
nodula. 

HALATION  DAFXMXTXOM  MAMAOBOMYi 
(COMMAND  IMVOKSD) 

nabuildCL8_define_relatlon(4,Class) . 

Provides  user  aeoees  to  the  relation  definition  facility.  The  nans  of 
the  relation  must  be  unique  to  the  elaee.  The  user  will  be  queried 
for  the  name  of  the  relation  (or  "auuaary  feet")  end  then  be  given  e 
list  of  choices  for  the  definition  (which  ia  e  listing  of  ell  the 
defined  end  inherited  properties  of  tha  class. 
aebuildCL»_reaove_ralat ic® ( ♦Clas# ) . 

onde tines  a  relation.  The  user  is  glvsn  e  nsnu  of  taxations  to  chooss 
froa,  which  will  only  include  defined  neabers  ef  tha  object  —  not 
inherited  ones. 
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msbuildCLl_view_ralation(+Class)  •  V 

Prints  oat  a  full  definition  of  a  ralation  ( "summary  fact")  to  tha  */ 

tacainal .  Tha  user  dose  not  apaelfy  tha  summary  fact  on  tha  command  */ 

lina  sines  para  ins  a  ant  ary  fact  name  ia  difficult.  lather,  tha  user  •/ 
will  ba  si  van  a  menu  of  all  outary  facta  to  aalact.  */ 

aabuildCULpodlf y_relat ion  ( +ciass ) .  *  / 

Allows  tha  uaar  to  change  tha  naaa  or  definition  of  tha  autary  fact.  */ 
Tha  autary  to  ba  aditad  will  ba  da  lac  tad  fro*  a  menu  in  rasponsa  to  */ 

tha  M wodify  autary  faet"  cctand  --  it  will  not  ba  a  menu  choica.  •/ 

This  operation  ia  restrict**!  to  defined  ambers  of  tha  object,  not  */ 
inherited  ones.  */ 


imOKTMD  TO  OTHIlt  MODOLSS)  */ 

mebuildCLS.  ,get_peiticl_reletion_detinition(  (+Name,  +Class) ,  -Daf)  */ 

Extension  of  sMbul  ldc  L8_de  f  ine_re  1  at  ion  for  task-laval  autary  facts.  */ 
MbuildcLS_get_auEXkary_£aet(+Cl«ss,  -giiamsryPact .  -Definition)  */ 

Extracts  an  objact-basad  autary  definition  */ 

*/ 

OPBRATXOW  DKPMITIOH  MMUUJ*K*MT:  */ 

(COMAMD  nrvoKXS)  •/ 

an>buildCL8_d«f  ine_cperation(+Class)  .  */ 

Provides  user  access  to  tha  oparatioa  definition  facility.  The  neme  */ 
of  tha  operation  must  b.i  unique  to  tha  class.  The  user  will  ba  */ 

queried  for  the  following  information!  */ 

Mat  --  The  oparatioa  name  suet  ba  of  tha  font  < prefix..  <direct  */ 

object>  <trail  phrasa>.  Tha  direct  object  oust  ba  the  cleat  name  */ 
or  a  valid  cesnponeat  name  of  tba  object.  */ 

Associated  Objects  —  iff  actively  an  argument  liat  for  tha  */ 

operation  (think  of  them  as  ths  dira.ct  and  indirect  objects)  .  */ 

Preconditions  --  Provide  tha  preconditions  for  all  objects  in  tha  */ 
operation.  •/ 

Intended  Iffect  —  Tha  single  intended  purpose  for  performing  tha  •/ 
operation,  it  ia  a  property  of  tha  direct  object.  */ 

Side  Iff sot  --  Tha  other  changes  to  the  cbjoets  in  tha  operation.  */ 
This  list  must  ba  a  strictly  determinate  list  (no  ponsibilities  */ 
or  probsbilltias  allowed  hare.  */ 

swbuildCLS_xaaova_cparation  ( -fClasa ) .  *  / 

Dndefinas  an  oparation.  Tha  uaar  ia  given  a  menu  of  operations  to  */ 

undefine.  You  may  only  remove  defined  operations  of  tha  object,  not  */ 

inherited  ones  from  parents  or  components.  */ 

mebuildCL8_view_operation(4Clasa) ,  */ 

Prints  out  tba  full  dataile  of  the  oparation  definition.  Xt  includes  */ 
all  tha  information  specified  about  in  mabuildCLI_dofiue_oparatiou,  */ 
plus  information  about  vbathar  this  oparation  la  defined  it  tha  class,  */ 
wee  Inherited  from  a  parent  or  ancestor,  or  vas  inherited  from  a  */ 

component  of  tha  object.  Tha  oparation  is  chosen  from  a  nenu  provided  */ 
through  this  command  —  not  by  a  eeamand-lina  entry.  <7 

*ebuildCLS_*odif  y_oper»t  lcn  (.;  class) .  */ 

Modifies  tha  operation  definition.  The  operation  is  chossn  from  a  */ 

menu  invoked  by  the  command  —  net  given  on  the  ccewmnd  line,  and  only  */ 
allows  tba  modification  of  defined  operations ,  not  inherited  ones.  •/ 

The  modify  oparation  command  allows  tor  ths  changs  in  ONLY  tha  */ 

Intended  atfacta,  preconditions,  and  side  effects.  You  CAKHOT  rename,  */ 
nor  raspselty  tha  indirect  objects.  These  era  t sapor ary  changes  due  */ 
tha  extrema  complexity  involved,  plus  ths  fact  that  it  would  ba  easier  •/ 
for  those  two  if  you  use  the  "remove  operation"  command  and  then  start  */ 
over  with  the  "areata  operation"  command.  */ 

V 

OPntATXQM  DISPLAY  SATA  MMHMUHTl  */ 

nebulldOLS_sat_operatioA_diaplay_data(4Preperty,+Class) .  */ 

Invokes  tha  operation  display  data  management  subcommand  loop.  This  V 
is  mostly  stubbed  out,  but  dose  contain  hooks  to  access  ths  graphics  •/ 
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•otelt. 

SNMON  DSFUtlTIOM  MAKXaSKXHT: 

(COMOND  XMVOUD) 

ambuildCU_define_daemon(+Daem©n, +Claas) . 

Provides  ussr  access  Co  tha  daemon  daf inltion  facility.  Tha  ussr  will 
ba  queried  for  the  following  information) 

Triggering  Condition  —  What  will  cauaa  tha  da  anon  to  become  aotiva. 
Activation  Type  --  whether  or  not  tha  daemon  will  advance  on  or  loop 
on  a  property  aet,  or  ita  activation  ia  baaed  on  applying  an 
operation. 

Advancement  Criterion  --  Whether  the  daemon  will  advance  baaed  on 
nuabera  of  turns  or  a  probability. 

Activation  Message 

mabuild£lj£_remeve_daenen  ( +  Daemon ,  -teles  a ) . 

Ondaflnes  a  daemon.  Muat  he  a  defined  daemon,  not  an  inherited  one. 
awbuildCb8_view_danaan  ( tDeemon,  tClaes) . 

Prints  out  ell  of  the  relevant  detailed  information  about  the  daemon. 
Including  whether  it  ia  defined  within  the  Class,  inherited  from  a 
parent  class,  or  inherited  from  a  component. 
nebuildCL8_jaodif y_daeaaon  ( tDeemon,  +  Class ) . 

Allow*  the  user  to  modify  aoa>e  of  the  attributes  of  the  daemon.  The 
daemon  muat  be  an  defined  daemon,  not  an  inherited  daemon  from  either 
the  parent  or  component  hierarchy. 

(EXPOATWD  TO  OTHKR  MODULES) 

ambuildCL8_get_background_f act (eclaa a, -Trigger, -Prob, -Type, -Msg) 
retrieves  Information  about  e  background  feet  of  the  Class. 
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TAB  3.  MEBUILDER  TASK  MODULE  (MEBuildTSK) 


IOI1DKA  Ttik  Definition  Nodule  --  Version  1. 01 

This  Module  Maneges  the  task  dete  structures  end  essists  the  user  in  buil¬ 
ding  consistent  task  definitions,  currently,  the  tesk  structure  uses  e 
a lapis  procedural  net,  covered  in  the  letter  steges  of  this  file. 

Version  History 

1.0  —  Original  version  releessd  to  the  students  for  the  experiaaant. 

1.01  —  Connsnta  are  updated  end  stubs  placed  for  eocMands  or  predicates 

needed  in  future. 

Z^ortsnt  Notes  about  the  Current  Versiont 
♦The  task  definition  laodula  contains  savsral  submodules,  each  of  which 
could  (should)  be  broken  out  into  a  separate  file.  Xt  present,  however, 
the  cosMunicatione  — ™g  the  subnodules  is  too  tightly  woven  to  wake  a 
clean  break.  The  submodules  would  bat 
—  The  NDulldar  intarfaca  portion 
—  Tha  procedure  graph  (or  procedural  net)  manager 
—  The  guaranteed  state  (or  situation)  nanagar 
♦The  task  definition  nodule  also  stakes  too  libsrsl  a  use  of  utility  pred¬ 
icates  frost  the  class  dafinition  modula.  (Thare  ars  scan  tan  predicates 
that  are  "exported"  in  mabuildCM  that  do  not  hagin  with  nebuildCLS_)  . 
♦Although  a  considerable  amount  of  work  has  been  devoted  to  Modularising 
NUuilder,  the  feet  remains  that  tha  intranodular  atruetura  of  this 
nodule  leaves  a  bit  to  be  desired.  The  procedure  graph,  guaranteed 
stata,  and  othar  subnodulaa  naad  to  better  conform  to  the  apecified  or 
intanded  intarfacas. 


A  task  establishes  a  tanporal  relationship  anong  oparatlona  whan  tha  oysr- 
etions  are  applied  towarda  a  specific  goal.  This  allows  the  teacher  to  i- 
dentify  relationships  between  and  anong  objects  that  tha  basic  cprrations 
thsMsalves  don't  cover. 


/*  Mttuildar's  task  fundament ala 

/a  eaaeaae. ••••••* 

/• 

/* 

/* 

/• 

/* 

/* 

/•  present at ion  of  a  task  to  tha  user i 

/*  currently,  a  task  is  given  as  a  sequence  cf  operations  or  sets  of  eub- 
/•  procedure#,  lacb  operation  ia  given  ■  stay  nunfeer  which  la  printed  in  front 
/*  of  the  cperetien.  This  step  number  ia  used  to  identify  eteps  when  being 
/*  manipulted  about  the  teak  (rather  than  having  tha  teacher  type  the  entire 
/•  cperetien  name  —  which  could  be  anbiguous  anyhow  since  an  operation  could  be 
/*  used  nor#  than  once.) 

/•  (1)  turn  tha  key 

/•  (2]  open  the  doer 

/•  CD  all  of  tha  following i 

/*  (Se]  subprocedure’ 

/a  [Sal]  take  the  money 

/•  [Sea]  run 

/•  [Sb]  subprocedure t 

/*  [Sbl]  cut  the  power 

/•  [3b2]  cut  the  phone  line 


*/ 

»/ 

*/ 

*/ 

*/ 

•/ 

•/ 

*/ 

•/ 

*/ 

V 
•/ 
•/ 
•f 

V 
*/ 
*/ 

V 
•t 
•/ 

V 
•/ 
•/ 
•/ 
•/ 

V 
*/ 
*/ 

V 

V 

V 
*/ 
•/ 
•/ 

V 

V 
•/ 
•/ 

V 
*/ 

V 
•/ 
•/ 
*/ 
*/ 

V 
*/ 

V 

V 
*/ 
•/ 
*/ 
*/ 
•/ 
•/ 
*/ 
•/ 
•/ 
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■  “  i  .  f  m  I 


/*  u4  cavMNti  Ml  OM  ntn  Mtty  far  M«k  UltiMt  property  ut. 

/*  <UitUl  ooUlliMi>  m  Hat  of  <prc^arty> 

/*  <okj  act,  leas  >  u  Hat  at  <cbjMtiw> 

/*  aa  4Hfttty>  I  lM*tttl(JU<piopaKy  a«t>) 

/• 

/• 

/*  itn a(«atty  IUI>I  <Mt|oUg  split  typa>,  <ipUt  joiminc  at-  .ja>, 

/*  (laooallf  rpllt  typa>i  <iasealag  tetioa  lists,  <«fUt  ataek>) . 

/*  tafilM  tk*  soda  fee  a.  Uik'i  graotol  «at.  fk*  follow  too  ua  tka 

/*  pattlealan  for  tka  irf  aim 

/•  -nuft  mm>  start  |  f  isa  |  cr*itk|*>  I  <cr-atay> 

t°  <0-atay>  mm  «<aMk*t> 

/•  <J>iuft>  ■»  iota  naakars 

/*  0  stays  Mt  Cor  sat  toss  oat.  tela  stays  ara  for  eoll-etiy  sod 

/•  dls—kl  gelatin  tka  jclaln  of  aetloos  tagatkar. 

/•  tsatfslig  split  typaxa  ao-aotloos  |  liaaar  I  or-split  I  sad-split. 

/*  < split  joist sp  staysea  -tO-stay> 

/*  <imeaiaf  split  typssaa  liaaar  t  joialsq 

/*  <laMslif  act  loo  liat>  »*  <laoeaiae  actios)  * 

/•  <  I  spool  an  actiuo>  •«  satay  aay  >  <  set  loo  lakw>  <  split  Ulst> 

/*  <  sot  loo  Ulu>  as  i actios  — ti  m  I  lasfeda 

/•  < split  iadsa>  ss  <aat«rsl> 

/*  *  split  laln>  trill  slssya  ka  1  for  aad- split  aad  liaaar  sts#os. 

/*  < split  ladar*  trill  ka  1  or  praatar  for  or-split  laps. 

/*  < split  staak>  ss  « split  stack  try  ■» 

/*  < split  atsrk  aotrv>  ss  «  split  stay*  aad  I  or  <  split  IMai> 

/*  fka  stack  of  apeo  splits  *«.  a  fins  stay. 

/*  fka  prcaadsta  act  dafiosa  tka  aaistaooa  of  aad- splits  aad  cr-splitt. 

/*  ao  sr-split  as  sac  tkat  tkara  arista  son  tksa  cos  sol  at  loo  to  a  caktssk 

/•  aad  tka  stalsar  aoly  kss  to  map  lata  oos  of  tka  salts  asks,  ka  sad-split 

/•  tasaas  tkat  tkara  arista  naltipl*  ssktssks  tkat  tka  stodsot  oast  parfero 

/*  all  of.  tka  si  soks  s  Iks  stf  ka  4mm  is  parallel,  so  tka  at  adapt  caa  do 

/•  sop  of  tka  act  I  cy  tm  tka  ssktaska  is  sap  ardor  so  loop  ss  erdar  is 

/*  nlaralaad  aaesp  tka  awktsska  (so  pltraa  safctssks  (a.k.a)  aad  td.a.t), 

/•  a  stadsot  cap  da  [a.k.e.d.a.f  1 .  (d.a.f .a.k.a) .  |a.d.k,o,s,t  1 .  ate.) 

/• 

/*  actlyl  slater  *».  isparatcr*.  « at  ap -tries  pnasrdltitp  Uat>. 

/•  <PtataUiatlr  aids  effect  list*,  iprakakilirtlc  aids  offset  lists. 

/•  kstiMS  rspsn  m  a  trass  it  isa  is  tka  precedes  *1  rat  (aad  tka  pat 

/•  oaolpalstlso  pact  iris  refer  to  sat  lay  y  -ttsaaltUa- 1 .  tka  eparater 

/•  la  snarly  stored  is  aarkaf  Coes,  kot  tkia  trill  aksry  ss  took 

/•  last  as*  1st  loss  jam  tka  1st  ay  trill  repairs  y  isatastiotakls  fay. 

/• 

/•  psaimr sadjstst a(<ataps>. rlist  of  paaraptaad  prapartiaai ) . 

/•  ksn  y  •payaoary.poataoaditiay*  is  praoiay  aocsiay  of  Mgprilter. 

!•  tka  list  at  pyraatyil  pnpartlaa  anas  1st  sf  a  List  af  aitkar  a  siaoia 

/•  prapartr  «  a  list  af  yltipls  y  spurt  isa  fry  tka  say  prnparty  set. 

/•  Iks  list  af  yltlpla  pwpptlss  la  kaaad  m  aaskod  pypartp  sots. 

/*  psrrostoadjstapy  an  noalsolatad  at  aaak  Any  is  tka  proaadsnl 

/•  prapk - 

/• 

/‘  Aa  aaaariarod  praps  aad  akarartart  trill  ka  rafarad  u  kp  tka  aas  af  pay 
/*  y  tka  priptad  ray  af  tka  sloas  da  aaorrmp  ta  staid  sakiyity.  p  «. 

/•  task  Mild  rspsir  flr»ni|ps  did  rpacaty  ca  m  tlsdUfdt  aoald  ka 
/•  darlarod  as  tsslUrspUr.npilnii.  IflaakMgkt.  tlsakllpkt)),  aad  tka  task 
/•  tsasld  ka  isatayiarad  as  taaklrapalr.rapalaaas.  Ulaakiiyti.flaakllpkta). . 

/• 

/*  Peso  task  is  aalarclasd  is  its  ay  yds  Is.  ss  tka  iatarfam,  tka  taaskar 
/•  trill  aalact  tka  task  to  aaxk  y.  fka  library  assay r  rill  saiatais  lafer- 
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/•  Mtta*  about  U*  d— aadaaalea  aa  the  1m*w,  l.a.  vhloh  eliaaaa  in  required 
/•  la  order  to  talli  the  tmm  —  tkn*  in  bml  lelily  ca  the  pn;  fact*. 

/• 

/•  Taaka  an  aot  directly  aooaaaad  by  ettilla  aodolea  bar.  an  laataatlatad  by 


nlitl«a(<nUtUa  m>,  « object  llat>,  <d»f laltloa>) . 

ftm  an  vary  aiallar  to  that  of  tba  iUu  lalliltln  arc— t  that  tbaaa 
relation  do  aot  dcaoriba  tba  atata  o(  aa  abject  hat  rathar  a  at  at  a  of 
tba  taak.  Aa  nu— ililloo  pcoocei  will  bare  to  toa  agra— ad  ao  that  tba 
<ralatioa  aane>  oaa  la  (act  taka  aa  object  a—  aad  aaah a  it.  Soaovar, 
tor  aoo  tba  ralatlea  aav  will  ha  aetahllabed  aa  la. 


a  (laeladi—  tbaaa  aot  yet  : 
oaa  ha  faaad  la  tba  tear ‘a 


of  aa  — eratiaa  vithia  tba  taak 


i  aot— *  la  tba  la 
by  tba  via*  taak 


areata  taak  (aaaad  <taak>) 
aoefe  aa  taak  (aaaad  <taek>] 
rawi  taak  ta—ed  «taak>] 
raatoc*  taak  (aaaed  <taak>] 

viaa  altaatioe  (la  <taak>l  (altar  rat— »f 

al aa  laltlal  aaadltlaaa  (la  <taak>]  (for  <objaet>) 

wiea  ohjaatloaa  (la  <taak>l  (for  <ebjeet>] 


wlaard  aa  I  off  (I 


1—  bit  far 


laltlal  anadltlaaa  (far  «ahjaat>) 
i  laltlal  nadltlaaa  (far  iahjaat>| 
abject lea#  (Car  nhjaat>l 
>  ahjaatl#aa  (far  «abjact>| 


Clad  —lit# 


(after  a— >| 


)  (with  ret— >) 


1  (with  a— >| 


/•  »Ui»il««jat,o»>Jn0i;lTnr_of_iaat«aca(.fTnak,atBataBca,+Claaa,-OBJ)  ■*/ 
/•  —  tho  cfejaotivoo  Pt  tha  aciaaa  efcjoet  in  *tuk  and  */ 
/*  iwtutUtM  tha  cbjMtivw  list  to  oeotti*  tbo  coocrete  xaataaoa.  */ 
/•  — frnlli1Ttn,aa»loya_objoot(aTaa k,KU»»)  •/ 
/*  —  tkodloata  that  aiMtooada  If  uy  object  of  typo  ciaaa  la  «aod  la  Task.  */ 
/*  onb*ildfaKjnt_atate_©f  ..ianugwa  ( ♦Taak ,  .Xaataaea ,  «Clnaa ,  *  Staff*,  -at  at*) .  */ 
/•  *•  m«atl*»ly  return.  tk*  i»a  tan  tin  tad  ywrantead  atata  lot  the  •/ 
/•  Taafaaat  «(  typo  dlnaa  la  lank  at  at age.  •/ 
/*  *oholl4HBMLget_lnat_choaaea_lai_laataac« ;  ♦tm)i ,  ♦In.taoee .  *ciaaa ,  aataga ,  •/ 
/*  •atata) .  V 
/*  —  Katana  tha  of  laatloo  of  all  tha  laat  e banana  or  tha  aigaifleant  •/ 


/*  ehaagaa  node  la  tha  mom4  Zaataaoa  ot  Claaa  prior  to  fort  htaga  la  •/ 

/*  tha  tank.  Oaad  to  help  dataniao  laaatarial  or  nalaportaat  goal  */ 


/•  aatvioa.  •/ 
/a  ■aim  1 1dTWi_ikpi,iU_taa)t<aTaak,»rlla) .  •/ 
/•  —  hand  oat  tha  taak  definition  la  aaaty  to  tha  Ilia.  •/ 

/*  •/ 
. . a . . . . . a. 
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TAB  4.  MEBU1LDER  LESSON  MODULE  (MEBuildLES) 


/ 

/ 

/ 

/ 

/ 

/ 

/ 

/ 

/ 

/ 
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/ 

/ 

/ 

/ 
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Means -tads  Lesson  Puildiag  Program  —  V*rs  1cm  1  (MXXaiLCXX) 

CW  ftcau  ».  Oalvin,  a.g.  Any,  Mml  for  t  graduate  Ichool,  Mo&taray  CA  93940 


NSPOZUWh  Imm  Definition  Modal*  --  Version  1.01 

Ail  Modal*  define i  Ait  *  Iuhb  i*  as  *  *truatar*d  ins  tent  let  ion  of  tuki 
object*  to  pMten  *  concrete  l*eeon  entity  runnable  in  the  Mens -end*  tu¬ 
toring  shell.  Xt  »l*o  provide*  a  quick  end  effective  Mini  of  building  be¬ 
ginner  level  through  advanced  level  probleee  in  the  apace. 

fcessoa*  oen*i*t  of  on*  or  nor*  preblana,  which  contain  different  scenario* 
and  provide  different  par  Masters  to  sons  of  the  probabilistic  avant*  in  the 
instantiated  task*.  The  intont  is  that  the  problem  ahould  be  ordered  in  in¬ 
creasing  level  of  difficulty  or  in  accordance  with  an  accepted  curricular  or¬ 
dering. 

Version  Mlstoryt 

1.0  —  Version  released  for  use  in  the  experiment  of  gunner  Quarter  94. 

1.01  —  Vareian  1.0  fully  doeanented. 


A  leseon  la  a  workbook  of  onorciaee  for  the  student  tr  perform.  The  exer¬ 
cise*  should  be  used  to  present  different  problem*  to  student,  in  general 
they  ehould  be  increasing  in  Ufficulty  and/or  complexity.  Examples  of  the 
different  types  of  problems  that  would  be  suggested  are  given  below.  Thee* 
types  could  certainly  be  combined  in  a  given  workbook. 

A.  Increasing  complexity 

Prob  1  ■  basic  task  with  all  negative  pitfall*  (i.e.  all  prob.  aid* 
of tecta  turned  off) 

Preba  2-n  e  sen*  tack  with  the  negative  pitfalls  given  inereeaim 
likelihood  and/or  adversarial  agents  vorking  foster. 

9.  bulk.  Crawl,  ban 

Prob  1  a  first  shank  of  task 

Prob  2  -  (n-i)  •  next  ebank*  of  task 

Prob  n  e  wbsle  task  (esaprehaosiv*  fashion) 

C.  Different  ggstgnsnt 

Prob  1  ■  task  on  *  basic  prop  (l.s.  cor) 

Picks  2-n  ■  task  on  more  .pacific  type*  of  prop  (i.e.  desses  tic  core, 
foreign  oars,  etc.  whisk  night  have  particular  needs  or 
osnsidsmtions) 

B.  Different  Deles 

Probe  l-a  ■  If  a  given  tank  has  n  team  mishit*  cooperating  together, 
then  far  each  preplan  give  the  student  *  different  role  to 
play,  hither  prab.  i  or  n  should  be  the  gey  in  ehorgn. 
h.  Different  Teaks 

i-m  a  Zf  the  library  contains  n  different  teaks  involving  the 
sloes  and  sans  sots  of  props  and  all  n  tasks  in- 
oabjoot  natter,  then  hake  the  atndant  ds  the 
at  •  tine.  (hx.  far  a  neahanic  and  a  ear 
,  ana  see  Id  hsre  the  student  replace  >'-be  water  pomp 
in  prehlan  1.  fin  s  feel  injector  in  preplan  2,  . . . ) 
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of  oosontt  objects  (proper  boom  ->  Jin,  Ala's  car  I  ate.).  Luiou  contain 
a  "east"  and  a  sat  at  "props" ,  and  catting  up  tha  lassos  la  dona  la  tanaa  ot 
naming  a  "setting"  or  a  "a cans"  and  having  tha  atudant  partem  a  "role"  in 
tha  aeaM.  Tha  task  oould  ha  viewed  aa  a  script.  Indicating  how  tha  aetora 
toahava  radar  ditfarant  atlnmll. 

Tha  lesson  itsalf  has  an  introductory  tart  along  with  tha  cast  and  prop 
listing,  Baoh  problem  consiata  ot  an  Introductory  tart,  along  with  tha  des- 
ariptiona  ot  tha  particular  scans  and  goal,  along  with  options  that  allow  tor 
ditfarant  bahavioura  among  problaaaa. 

Tha  intant  of  tha  muildar  systaa  ia  to  have  tha  taaohar  apand  tha  najor- 
ity  ot  tha  tins  hara,  at  tha  highaat  laval  ot  tha  Mbuilder  hiararohy  —  do* 
lag  choreographic  and  situational  things  rather  than  digging  in  tha  waada  ot 
tha  task  and  abject  layers.  Tha  llhrary  nanaganant  syatan  ia  thara  ao  a  huge 
reusable  objact  library  oould  be  oraatad  of  both  objects  and  tacks.  So  tha 
laaaan  interface  needs  to  bo  tha  boat  robust. 


NIBuilder'a  lesacn  definition  data  structure 


a  lesson  is  defined  aa  tha  eenposita  of  the  following  facta  partitioned 
within  tha  sane  dynamically  declared  nodule.  Khan  a  lesson  ia  compiled  into 
naane-anda  tom,  this  data  structure  will  help  keep  repetition  to  a  ainlann. 

Tha  asaooiatad  elaaa  definition  information  la  ecpled  in  to  assist,  however 
tha  tasks  are  mot  copied  into  tha  dynamic  module.  Their  information  ia  kept 
singly  instantiated  in  its  own  nodule. 

■MIC  uikc  raer*! 

laaaaalUaaatA  pens*,  -coast >,  <prope>,  <taska>) . 

The  claaaoa  nama>  is  strlotly  unique  to  tha  environment .  Tha  oast  nmat 
ha  non  anpty.  Tha  list  of  tanka  are  a  subset  of  all  those  which  could  be 
instantiated  from  tha  <oaat>  and  -c props > .  Tha  <cast>  and  «propa>  are 
3 -tuples  of  (< Instance  name>  <claea  mm>)  or  more  appropriately.  (<rola 
name /prop  mamae  colaesv) .  throughout  this  nodule,  cant  manfeern  will  be 
referred  by  tha  lx  role,  and  prep#  by  their  prop  name. 

1 acorn  let  in  ( it  art » ) . 

tidal  intro  duct  lam  tot-  tha  lesson. 


problem ( ruunln a r » «  «nna>,  < student ' v  rolar,  coast >,  <propa>) . 

The  problem  fact  provides  tha  basic  information  for  tha  problem .  The 
•ant  and  prep  arguments  allow  the  teacher  to  specify  that  a  cast  msafear 
or  prop  la  a  derived  clans  of  that  given  in  tha  lesson  level,  generally, 
the  east  i.nad  are  and  prop  lists  natch  that  of  the  lesson. 

Mil  Currently  there  in  ao  hook  in  place  far  problem  options.  Tha 
aidn_ef  f act _ov*rr? da  below  la  sort  of  a  hook  hat  it 'a  not  uaed.  They 
sen  Id  ha  planed  aa  a  ninth  argmaant  here  or  they  could  bo  laplaaaaated  ao 
operate  facta  (in  fact,  tha  cast  and  props  oculd  ha  treated  in  override 
fashion  an  veil) . 

lnit  ial_  sett  lag  ( vaambar> ,  <  initial  somditicn  list»;  . 

hmalnpaus  to  tha  ialtlal_oomditlsae  of  snob  task,  accept  thee  the  initial 
netting  ia  a  aaapoaite  ad  nil  tha  initial_oandit ions  of  each  prop. 

objective*  («aanbsr>,  <out  mUar>,  <abj active  liet»). 

Unlike  tha  initial  aottiag,  the  ebj actives  axe  broken  cat  by  cast  aintir 

will  bn  naad  ta  derive  the  arast  facta  la  tha  natutcr  lesson.  Also  nets 
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that  tha  objaetlvaa  par  eaat  member  era  fixed  for  all  problems  In  eha 
laaion.  This  la  tha  global  "raating  a tat a"  for  tha  eaat  member. 

problaat_intro(<nuaber>,  «taxt>) . 

Introductory  text  for  tha  problam. 

alda_af  f ect_ovarri.de  ( (number > ,  <op> ,  <contazt> ,  <  change  > ,  <prob> ) . 

NOV  nttUmWID .  TM§  wee  tha  firat  awag  at  a  problem  option  concept. 
Xt  May  be  auffieiant  for  tha  avant-apaeif ie  prebabllitiaa,  hut  It  la 
probably  batter  to  have  a  more  global  options  construct . 


Co— made  provided  by  this  Module  (Including  those  not  yet  implemented) 
Document  at  ion  on  these  cn— anile  can  be  found  la  tha  uaer'a  manual. 


mason  command  bcpoatxd  to  ora*  loomi  loops i 

create  laaaon  [named  < lessons]  Main 

work  on  laaaon  [named  <cleason>]  mo, in 

remove  laaaon  [named  <laason»)  Main 

restore  lesson  [named  «lessoa>)  Main 

check  laaaon  [named  <leaaon>]  All 

view  laaaon  [named  <laeaon>]  All 

oompila  laaaon  [named  <laaaon>]  All 

run  laaaon  [named  4aanfla>1  All 


The  Laaaon  Loop  la  invok'd  through  tha  create  laaaon  and  work  on  laaaon  cads. 
LBMOM  MANIPULATION  CQMAMMi  LOOPS i 

visard  on  I  off  (Undocumented  nr  Minis)  Lesson 

■ata/Kaloaaaa  tha  debug! lag  bit  tor  naans -ends 

Laaaon 
Laaaon 
Laaaon 
Laaaon 
Laaaon 


aback  laaaon 
view  laaaon 
eonplle  laaaon 
run  laaaon 
adit  laaaon  intro 
view  laaaon  intro 
ornate  problam  [na 
work  am  problam  (n 


<problan>] 
sr  «problem  ao>] 
1  <problaai>] 


remove  problem  (mambas  (problem  mo>) 
ramava  problem  [named  <psoblem>l 
aback  problam  (member  (problem  mo>] 
ebook  problam  [aimed  (problems] 
view  problem  tammbar  (problem  mo>] 
view  problam  (earned  (problems] 


via  tha  create  problam  aad  wort 


the  dabugflag  bit  tor 


viam  problam 
edit  problam  intro 
viam  problam  intro 

amt  enema  (tor  (most  martor  or  props] 

mat  pool  (for  (east  member  or  ptep») 
view  gool  [tor  swat  member  or  prapn  ] 
mot  apt  isms 


problam  omds 


Problem 


Problem 

Problem 

Problem 

Problem 

Problam 

Problem 

Problem 

Problam 

Problem 
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/•  upetttd  Predicates.  All  predicates  intended  ter  external  use  are  pralixad 
/•  with  «nebulldL*S_“  except  for  those  free:  tha  lesson  ocellar  "■abuildCW_" 


MU1I  APPLICATION  LOOP  —  APPLICATION  PMDICATXS: 
nabuildLM.setup. 

—  Initialises  all  tha  dentins,  ao— ends ,  aad  template#  tor  tha  main 
nabuild  application  go— and  loop. 

MbuildLB£_laaaoh_daf  i:\itloA_initlallsa . 

initialises  tha  lasson_deflnition  datahaaa. 
mabuildLM_les  son_daf  init  ioa_shutdown . 

—  claaxa  all  lesson_def initien  facts  front  tha  Prolog  datahaaa,  erasing 
all  dynaadoally-oraatad  nodules.  Osed  by  Ktnuild's  quit  ccemmad. 

mobuildLSS_append_autoseve . 

—  Appends  all  laaaon  definition  data  in  nanozy  to  the  autosave  file. 

COMOXD-ZWOKZD  PMDICATXS  POA  MAIN  APPLICATION  LOOP: 
snbuildLXS_define_le#soa< ♦Lesson) . 

••  Provides  user  aooass  for  creating  a  new  task*  Invokes  tha  task 
building  application  loop  on  tha  newly  created  task. 
ambuildLM_rsmove_leaaoa(^Lesaoa) . 

—  narks  a  lesson  as  "deleted*  (refer  to  library  nodule) . 

nebuildLXS_r#atore_lesaon( ♦Lesson) . 

—  Kastores  a  renoved  lesson  in  naaory  (l.a.  undeletes  it) 
*ebuildLXS_work_on_lesson< ♦Lesson) . 

..  in  (if  not  loaded)  and  invokes  the  lesson  building  application 

loop  ot.  an  existing  lessen. 

COMKAMD-XXVOnD  PMDICATXS  IKN  lil« NOW  LOOP  MAT  AU  ALSO  XXPOATXDi 
—buildLXS_ohack_leeeee<  ♦Lesson) . 

—  Performs  integrity  cheeks  on  all  east  members,  preps,  tasks  aad 
problem  to  ensure  that  the  lesson  could  be  run  successfully. 
nebuildL*S_view_iesson<+Leesoa) . 

--  prints  out  a  table  of  all  the  prlnary  lessen  data. 

cnbulldCX?_OQ—ile_lessoB( ♦Lesson) . 

„  the  lessen  in  MTutor-readabie  for*  and  saves  to  a  .pi  file 

on  disk. 

— hui IdUMLNNM-less— Ceh— sea) . 

—  invokes  the  muter  shell  in  order  to  run  a  lesson. 


to  the  file. 


ert_lessouULesece,  ♦Pile) . 

it  the  lessen  definition  in 
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TAB  5.  MEBUILDER  LESSON  COMPILER  (MEBuiidCMP) 


Huu-ndi  Lesson  Puilding  Program  --  Vardan  1  (KUOXLDZX) 

CP*  Acmi  P .  Salvia,  u.n .  Any,  Maval  postgraduate  School,  Monterey  CA  93940 


MDOILDSR  Laaaon  compiler  --  Vara  ion  1.01 

Tha  KDulldar  laaaoa  eeapllar  takaa  an  KtXuildar-cona  Cruet  ad  laaaon  and 
craataa  an  naana-anda  convaraion  of  it  into  an  ana logoua  databaaa  partition. 
Tha  databaaa  partition  ia  nanad  tha  a  uaa  aa  tha  laaaon  itaalf  except  that  it 
contains  tba  addad  aadiag  *_ne".  whan  a  laaaon  ia  ran,  tha  partition  aant 
to  tha  netutor_shall  ia  tha  _»a  partition. 

MOTMi  Mood  to  oatract  all  laaaon  eaehing  atuff  out  of  tha  nebuild^claae 
dafinition  and  gat  it  in  hara  in  ordar  to  aehiava  aoaa  dagraa  of  eonaiataney. 

Varaion  history  t 

1.0  —  Varaion  rolaaaad  for  uaa  in  tha  fluaaaar  Qtr  94  arporinant. 

1.01  —  Fully  on— antod 


Saaerlption  of  tha  Caag>llation  prooaaa 


Co—iletlon*  ia  probably  a  laaa  acourata  daaeription  of  what  happana  hara 
tram  lation* .  Paaioally,  tha  laaaon  rapraaantatlen  conatruotad  in 
MBPttildar  torn  ia  tranalatad  into  a  form  that  MBTUtor  can  uaa.  ghat  ia,  tha 
prooodural  not  and  olaaa  doflnltlena  ara  eonvartad  into  a  sequence  of  roaon- 
nended,  precondition,  addpoateondition,  and  dalatapoatocndltion  elauaaa  — 
along  with  all  tha  othar  elauaaa  that  MRuter  uaaa  aa  aupport  —  auoh  aa  tha 
randohanga.  aingular.  plural,  ate. 

tha  laaaon  oompilar  will  than  attoapt  to  aolva  tha  problan  in  aa  many  vaya 
aa  feasible  in  ordar  to  dataet  any  ml  matching  of  tha  inatantlatad  taaka. 

Tha  algorithm  for  doing  this  ia  daacrlbod  balow. 


following  la  tha 


(1) 


(a) 


of  aationa  that  tha  laaaon  ooapilar  dooa> 


intagrlty.  (Performed  by  nabuild_claaa_dafinitioa) 

Dafinition  integrity.  All  proparty  definitions,  operators, 
oenponauta,  ate.  —at  ha  n  rag  lately  and  oenaiatantly  defined. 
Chants  lor  arrors  which  nay  ooour  whan  an  operator  ia  defined  and 
than  tha  praparty  sat  it  la  dafinad  —  la  dalatad.  Failure  ia 
fatal  and  ooapllatioa  stops. 

<b)  oafinition  Co— latanaas.  All  propart ioa  ara  tastad  to  anaura  they 
have  an  asaoelatad  operation  (however,  of  oouraa,  ao—  propartlaa 
will  not  have  operators  which  asks  than  ooour) .  failure  only 
and  eoopilation  oontl 


(I) 


tush  Integrity 

(n) 


(Part earned  by  nabaild_taah_datinition) 

Integrity.  Aa  prooadaro  net  neat  ha  o loved  with 
■a  "start*  and  "do—"  a  Cages ,  nasal  ag  that  there  —at 
with  no  outgoing  aetious  tad  all  —at  reach  *do— *. 

—at  reach  “return* .  Any  severed 
u  wonpletaiy  savaged  and 
will  only  paodaau  a  wanning  naaaaga.  All  othar  prooadaro  net 
integrity  violet  Iona  ara  fatal  and  n— llitlnn  stags. 

(b)  Abtion  Xntagrity.  Aa  varioaa  actio—  in  tba  net  ara  than  tasted 
to  insure  that  all  ag  ara  tors,  propartlaa.  ate.  ara  defined  by  tba 
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class  definition.  Failure  it  fatal  and  eowllatloa  stops. 

(o)  Split  Integrity.  AND- splits  must  Uvt  lags  which  srs  Mutually 

exclusive  is  activity  (however,  Type  XZZ  preconditions  ars  still  OK 
for  forcing  a  partial  ordering  of  AMB-aplit  actions) .  ox-split 
initial  actions  Mist  all  act  on  ths  sans  proparty  sat  and  hava  an 
antsy  pxaconditioa  which  is  an  unusad  nanbar  of  tha  proparty  aat. 
Failure  is  fatal  and  compilation  steps. 

(d)  tenant ic  Integrity,  the  gaarantaad_atata  at  “dona"  auat  contain 
tha  objectives  without  possibility  of  other  etatae. 

(3)  Xioason  integrity.  (Performed  by  nabuild_lasaon_datlnitloa) 

(a)  Object  Integrity,  insures  that  tha  east,  props,  and  tasks  are 
consistent  as  declared  for  the  laeson. 

(b)  objective  integrity.  Insure*  that  tha  objectives  listed  exist  for 
the  cast  and  prop  neobara. 

(c)  Problem  Integrity.  Insures  that  tha  initial  Bettings  and  tha  over* 
rldas  for  each  problan  are  wall -defined  and  consistent. 

(4)  Translation,  (performed  hare) 

The  specific  algorithms  for  the  translation  of  the  naans-ends  facts  are 
described  in  tha  translation  section  of  this  file. 

(5)  Lesson  Testing,  (parforawd  hare) 

The  individual  tasks  are  tested  for  sonant ic  and  traversal  integrity. 

Not  sura  yet  what  it  will  swan  to  traverse  a  full  forest  of  procedure 
graphs. 


NUuildar's  Compiled  Lesson  data  structure 


Tha  eospilatlon  data  structure  f c  -  MDuilder-besed  lessons  use  a  taaplatad 
form  of  tha  means -ends  search  space  —  i.e.  it  uses  macros,  future  Implem¬ 
entations  of  UNuildar  might  find  iv.  batter  not  to  uee  macros  —  but  tha 
advantage  of  uelug  macros  ia  that  large  volumes  of  lesson  material  can  be 
stored  in  less  apace.  The  disadvantage  is  that  naero  expansion  ia  dona  at 
nn  time  which  is  slower- 


Sens  of  these  macros,  fortunately,  cam  ha  directly  determined  from  tha 
class  definition  nodule  —  requiring  no  additional  translation  for  affect, 
these  are  tha  hidaable_f acts ,  eummary.facta,  singular,  and  plural  designators 
foe  oemponaute,  the  daemon-based  ramJohanga  facta,  and  tbe  class-defined 
display  data  Information  tor  properties  and  operations.  (NOtli  Currently, 
not  all  these  will  work  properly  since,  for  araspls,  summary  facta  are  single 
object  items  at  thin  writing  end  arc  mot  included  for  teaks  and  lessons, 
aanmnxy  tacts  are  also  recursive  hy  design  bat  sot  Implemented  as  such  yet. 
Those  are  shortfalls  being  worked  on  at  this  masiant. 


The  following  are  the  ccapilod  loosen  facta  ter  this  version.  Tha  macro 
expamaiam  does  at  rant  ins  pcodaess  Inst satiated  farts  which  da  not  contain 
the  added  “_f  sad  lag.  These  without  a  *_f  ending  era  not  macro  expanded. 

Tha  tsaplate  farms  are  own  of  two  types  and  are  boned  cm  clone  dams Iasi 
♦Template  tie  «olass>r 

♦Quant if ledTWTplats  ns  (eena(«elnns>),forall(<clas»>) 

The  amubere  of  thn  tsaplate  are  referenced  ia  tbs  body  of  the  .wire  as 
arg(X)  or  porg(X)  far  tha  cbjaet's  earns  sad  possessive  forma  (if  followed 
Ay  tha  assonant  asms  for  prepaxtiaa  and  opera t ions  cm  eeacwoemts, . 

Manra  baaed  orgenamta  far  prepaxtiaa,  aparatiana,  at  a.  will  be  listed 
aa  ManroPrepsrtyfcist,  User  separation,  etc. 

HOTS)  Par  aaaaa  wham  there  in  exactly  sms  el  enact  ia  tha  dwelt  for  all 
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9 


problem*  ia  th*  Uiiu,  th*  laaaoa  ecapiler  will  pattern  partial 
aaere  expansion  (still  praaarva  th*  “_t"  macro  term  hat  reduce  th* 
Mero-argumants  to  expend) . 

MOTBi  Dead  to  arplera  tha  agent  fact  te  aaa  it  it  really  la  headed  new. 

leeaoa(-taaM>) . 
l*eion_iatro(<t*xt>) . 

Copied  from  tha  laaaea  datiaitlea. 

goal_t ( < quant if lad  template*.  <aaere  property  liat>) . 

■arvaa  a*  tha  a  lag  la  goal  liat.  If  aay  templet*  elements  ax*  quant i- 
fiald  existentially,  than  aultipl*  goal  fact*  will  fe*  expanded  and 
aatiafyiag  aay  ea*  will  b*  sufficient  for  aehiaviag  th*  goal. 

Thar*  ia  oaly  one  go*l_t  par  laaaea. 

problem ( <probl*at  number > ,  <problam  name*.  <atud*at  rel*>) . 

Partial  facta  copied  from  th*  laaaoa  definition. 

preblaaL.domaia ( <problaa  number*,  <elaaa>,  <lnataac**>) . 

Uaad  to  supply  tha  n*m*»  of  tha  object*  of  Ilka  type  ia  th*  *rg(X>  and 
arg(X)  facta,  it  la  an  expanded  copy  of  tha  reduced  eaat  and  re-  * 
dttsad  pro*  arguments  in  th*  laaaoa '  a  problem  t net . 

problam_int ro ( <prob\aa  number* ,  < t ext > ) . 
hlao  copied  from  th*  laaaoa  definition. 

start_st*ta_t(<prablam#>>  < quantified  teaplete*.  «naero  property  li»t>) . 
»tart_*tate_t  is  a  macro  which  currently  will  always  have  u  null  tem¬ 
plate  and  a  fully  expanded  <macro  property  list*. 

sintful*r_t (<t*oplat*>,  <macro  object*). 
plural_t(<t*nplat*>,  <macro  object*) . 

Tor  componenc '  *,  <tamplat*>  will  be  a  single  class  entry .  Full  cast 
ammbars  and  props  who  us*  singular  and  plural  tacts  will  use  a  null 
templet*  and  a  fully  axpaadad  naan  in  th*  Mero  object  argument. 

It  These  macro*  are  fully  elaaa  defined  and  are  produced  by  tba 
n*build_ol***_dafinltion  module. 


<Mero  context*  , 


<macro  context*. 


:(<role>,  < templets*.  < macro  property  list*, 
macro  operation* ) . 

precondition^  (<xola>,  <t •splat**,  <macro  operation*. 

<maevo  praoondition  liat*) . 

addpo*tcondition_t (<rola>,  <taaplata>,  < macro  operation*. 

<macro  addpoatcondition  liat*) . 
delet*posteondition_t(<role>,  <t*mplat**,  <Mcro  operation*. 

<maoro  daletapost condition  Hat*). 

The  teaplated  form*  of  th*  mean* -ends  facte.  Th*  <rola>  argument  ia 
optloMl.  but  would  be  produced  whenever  the  rule  applies  to  a  east 
other  than  th*  student's  role. 


aero  context*, 
macro  count /prob*. 


i(«tamplat*>,  < macro  application*,  < 
rmafirn  delate  list*.  <macro  add  liat*. 

<macro  aeaaage*) . 

readme  events  that  occur  —  or  thee*  events  that  occur  in- 
Of  n  user's  action,  manrn  application*  includes  init, 
to  uiiha  change*  at  th*  start  of  th*  problem  or  any 
tamplated  eperutiem.  emote  count /prob*  corresponds  te  tba  us*  of 
u canters  or  probabilities  to  iadieet*  activation  of  ths  randchange 
(Cnrrently  it  Is  only  smaeto  prob*  wbicb  is  n  raw  probability  value, 
at  neeroa  nr*  mot  yet  iaplamemted.)  <macro  delete*  and  mure  add* 
property  Hate  aad  macro  message  is  *  message  template  for 
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warning  output  to  tha  student 
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hlrtaahla_tacts _t (<qu entitled  teaplate>,  <uoio  property  aot  um>i 
tMOM  propatty  aot  oaoban*) . 

Allova  tAa  MXTutor  ahall  to  identify  what  information  la  to  be  with¬ 
hold  from  tho  uaor  whoa  tho  unknown  ( <a«pended  proparty  aot  um>)  loot 
la  trua  la  tho  currant  a tat a. 

MOTS i  Thaaa  macros  ora  fully  slaaa  dofiaod  and  ora  produeod  by  tho 
Mhuild_eloaa_dofinltioa  aedule. 

euwasy_faot_t(<taoplate>,  <aiaro  summary  facts,  <macro  definitions) . 
Provides  tho  ralotloa  dotlaltloaa  for  tho  leaaoa. 

apply_text_t ( <teaplate> ,  aaacro  oparotloa>>  <macro  contexts,  <maaro  msg>) . 
Provide  messages  that  will  ovorrlda  tha  dafoult  apply  tort  information 
generated  by  tha  MlTutor  ahall. 

IMPORTANT  MOTIi  Tha  original  iatont  voa  that  tha  toaplotoa  would  bo  mini¬ 
mised  la  ordar  to  taka  advantage  of  things  Ilka  single-object  domains . 

Thla  oonoapt  voa  abandon ad  booouaa  tharo  wara  aiff&if leant  problaaa  In 
KM Tutor ' a  macro  expansion  proeaaa  whan  tha  single-object  domains  happanad 
to  ba  tha  atudant ' a  rola  and  tha  foot  would  up  with  a  null  taaplata .  Tha 
roault  woa  that  toms  foota  wara  not  baing  ploood  In  flrat  paraon  fem. 
hanoa  eouaing  unaolvobla  problems.  Therefore,  “all*  nouns  ora  listed  in 
awero  oa  typaa  and  no  streamlining  of  toaplotoa  la  dona. 


Exported  Pradleotaa .  All  prodicataa  intend ad  for  external  uaa  oro  prefixed 
with  "aebuildCMP_" 


APPLICATION  FAKDICATISt 
nabuildCMF_setup . 

—  xaltiollaoa  all  tho  dcataina,  of, wands,  and  toaplataa  f  jr  tho  win 
Kabul  Id  application  coaaaand  loop,  (should  only  bo  toaplotoa) . 

aabulldCKP_aoopilar_lnltioliao.  (Main  App  Znlt  koutino) 

—  Xaltiollaoa  tho  ooapllod_looaon  database. 
nebuildCMr_eempiler_sbuCdovn.  (Kola  App  Doao  heutino) 

—  Cloaro  all  eoapllod  definition  faete  from  tha  Prolog  database  and 
orasao  all  dynamically  croatad  aodulas.  Daad  by  MBBulld'a  quit. 
mebulXdCMF_appemd_eutosevo.  (Main  App  loop  routine) 

—  Appends  all  eoapllod  lessons  in  swory  to  tho  autosave  file. 

COMPILE)  4JWSOM  MUnuSSKBHTi 

mabuii4Ciir_eeacila_lesaoa<+Lesson) . 

—  Top -level  loaaoa  compiling  function,  guecaoda  it  compilation  par- 
fora*  to  eeaplotloa  with  CcopilodNod  containing  tha  ccapllad  form. 
Xf  failed,  eoapila_la>son  will  fall  and  tha  data  la  tha  unraturnad 
CcaplladMod  la  undefined. 
mahuildCllP_sawo_caapilad_laaa«b  ( ♦Lesson,  arils ) . 

—  snips  tho  eoapllod  for*  of  Loaaoa  Into  tho  fllo  Mils,  rile  la  than 
a  fully  muter-runnable  lasooa. 
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TAB  6.  MEBUILDER  LIBRARY  MANAGER  (MEBuildLIB) 


. . . . . . . . . 

/*  MtucbAi  Lesson  xullding  Irogru  --  Version  1  (KEAQXLDIX)  */ 

/•  CJt  Dhmi  t .  stlvis,  U.i.  Anv,  Havel  Fostgraduate  School,  Montsrey  ex  93940  */ 

/•  mauZLBn  Library  Msnagamo nt  Module  —  Version  i.02  (mabuildLXl)  */ 

/*  */ 

/•  Version  Updates  */ 

/*  1.0  —  Fundamental  add,  load,  and  save  operations  built.  */ 

/*  1.01  —  Compiled  file  Management  added  aad  Queries  for  unsaved  changed  */ 

/*  added.  */ 

/*  1.02  —  Added  procedural  stubs  for  delete  aad  undelete  cosssaads  a  purge  */ 

/*  library  coewand,  aad  the  link  management  commands  (add  link,  */ 

/*  remove  link,  plus  others),  the  purpose  of  the  stubs  is  to  allow  */ 

/•  easier  inclusion  of  these  eeaaaanda  in  future.  */ 

/*  Code  has  been  thoroughly  coemented  to  describe  decisions  made  and  */ 

/•  requirements  for  future  implementation.  */ 

/•  */ 


/°  MBbuilder's  Library  data  structure 
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the  local  library  is  stored  in  ./lib  from  the  teacher's  working  directory 
The  directory  contains  a  special  file  called  “mebuild.lib11  which  stored  the 
library  information.  The  local  library  is  prolog_file_type  marked  with 
mebuil4_looal.JLlbrery_clefiaition_file.  the  following  is  the  library  data 
structural 

\ibraiY_claes_entry Uclass, +FileHeme, «DateTime-Stanp, +ciassQ*pandencies) . 
libr*n*_task..sntry(+Tnsk, +FileHeme,+HateTime-6taap,  eClaasDependencies)  . 
library_lessoa_entiy  (  .lesson,  *r  iletiame ,  ♦DeteTime-8t amp,  ♦ClessPependencies , 
etas  kEey endencie  s ) . 

--  Filename  ij  scored  as  an  absolute  file  bams,  to  prevent  problems 
when  running  MKBullder  from  other  directories.  Xf  FileMama  is  the 
keyword  “none'',  then  this  object  has  been  creatad  during  the  current 
session  only. 

--  Datstima-Atr  v  provides  the  system  time  that  the  class  was  last 
updated  using  Quintus  Prolog ■ s  dsts  library,  this  hslps  identify 
when  other  claesae  or  lessoue  need  to  be  checked  to  ensure  the 
versioning  date  is  ox.  The  keyword  ‘urns"  is  sems  es  for  Filename.. 

—  Dependencies  are  lists  of  clesses  that  any  entry  depends  on.  these 
other  entries,  if  not  updated  la  the  current  database,  will  be 
called  in  automatically. 

llbraxy_llak  (+LibrexyMeme ,  sKamoteLibraryDlractcry) 

•«  Allows  a  taachar  to  aeeaas  another  local  library,  as  Icag  as  it's 
file  protection  is  read.  Classes  import'd  from  linked  libraries 
will  be  read-only. 

—  Libraries  will  have  a  library  name  tag  that  will  be  used  by  the 
interface  ret her  than  the  directory  name. 

clese_ia_databeae(+Claee , cleenldirty, iMewClassPep) . 
task_in_datebeae (steak, cleenldirty, ♦MewC las  eBay) . 
leseon_in_databaae ULeason, cleenldirty,  iMswClsssPap,  ikawtaakDep) . 
nmgi  Uatioa_la_databa  asULss  son,  current  lnot_curr»at) . 

—  Indicates  the  item  has  bean  modified  and  has  the  given  maw  depen¬ 
dency  lists.  Compilation  status  is  either  currant  or  aot_current . 

For  the  purposes  of  using  the  module  reservation  system  in  utility  (which 
is  maw  for  this  veraiem  —  the  tenant  mama  is  always  class (<class  names). 
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task (.task  um>)  ,  laason(.leaaon  name.),  er  coaplessoa(<laason  g«u>). 


/ 

/ 


. . . . . . . ....../ 

f 

Ccmli  provided  by  this  nodule  (including  those  net  yet  Implemented) 

•/ 

/• 

/• 

Documentation  on  theee  commands  can  be  found  in  the 

u»«r 

*  * 

•s  manual. 

*  * 

*  •  * 

•/ 

•/ 

/• 

/• 

LIBRARY  MAHAOBMBNT  COMONDSt 

LOOP St 

V 

V 

/• 

create  library 

Mein 

*/ 

/* 

view  library 

All 

*/ 

/• 

view  remote  library  (named  .library.] 

All 

•/ 

/• 

link  library  [named  .library.] 

Mein 

*/ 

/• 

unlink  library  [named  .library.] 

Main 

V 

/• 

purge  library 

Main 

•/ 

/• 

CLASS  ENTRY  MANASBMXHT  COMMANDS  i 

*/ 

/* 

load  object  [named  .claea.l 

Main 

•/ 

/* 

wave  abject  [named  .claee.) 

Mein 

*/ 

/* 

TASK  ENTRY  MANAGEMENT  COMMANDS  I 

V 

/* 

load  task  [named  .task.] 

Main 

*/ 

/• 

save  task 

Task 

*/ 

/• 

save  task  (named  .task.] 

Main 

*/ 

/• 

LISBON  ENTRY  MANAQXtONT  COMMANDS  i 

*/ 

/« 

load  lesson  [sand  .lesson.  1 

Main 

*/ 

/• 

save  lesson 

Lesson 

V 

/* 

save  lesson  (named  .lesson.] 

Main 

•/ 

/• 

save  compiled  lesson 

Lesson 

•/ 

/* 

save  compiled  lesson  [named  .lesson.] 

Main 

*/ 

/* 

•  *  * 

*  * 

*  * 

•  *  * 

V 

/* 

Bxported  Predicates.  All  predicates  intended 

for  external  use  era  prefixed 

*/ 

/• 

/* 

vith  umebuildLZB_" 

*  •  • 

*  * 

*  * 

•  *  • 

*/ 

•/ 

/• 

/* 

APPLICATION  PREDICATES > 

*/ 

•/ 

/* 

mabuildLIB.sa tup . 

•/ 

/• 

--  Initialises  all  tbs  domains,  commands,  and  taoplatss  for  the  main 

*/ 

/• 

swbuild  application  /  claes  building  loop 

*/ 

/* 

aebulldLIB_i.nclude_task_cnaras.nd.  ( ♦  LoopNams 

♦TaskNaraa) 

•/ 

/* 

—  Makes  available  those  oommands  which 

era  to  be 

allowed  in 

task 

V 

/* 

building  cosnand  loop 

*/ 

/* 

BMbuildLIB_includa_lesson_ccauiids  (♦LoopName,  .LessonNaae) 

•/ 

/* 

—  Makes  available  thoee  commands  which 

are  to  be 

allowed  in  ths 

lssson 

*/ 

/* 

building  command  loop 

•/ 

/• 

siabuildLIB_ltbrary_  initialise .  (Main  App 

Init 

Predicate) 

•/ 

/• 

—  Initialises  the  library  database  to  be  sapty. 

Calls  shutdown. 

and 

*/ 

/• 

than  loads  in  the  system  end  local  library  files. 

•/ 

/• 

mebulldLIB_llbrary_ahutdown .  (Mein  App  Done  Predicate) 

•/ 

/* 

—  Cleans  the  library  information  from  ths  Prolog  database. 

Acts 

upoa 

•/ 

t* 

any  dirty  items  in  the  library  interactively. 

*/ 

1  /• 

mebuildLZB_append_autosav*  ( .nutoaavePils) 

V 

/* 

(Main  App  Loop 

Predicate) 

V 

/* 

—  Appends  ell  library-based  date  item. 

into 

the  autosave  file. 

•/ 

/• 

LIBRARY  MAMAOTWHT  (ALL  COMMAND- IMV0K1D)  I 

V 

/• 

mabuildLI>_create_llbrer y . 

•/ 

/* 

—  Creates  a  new  library  directory  in  the  current  working  directory  end 

*/ 

/• 

initialises  ths  mebuild.lib  fils. 

*/ 

/* 

mabuildLZB_visw_li br ary . 

•/ 

88 

t* 

—  Print  ■  out  a  Hating  of  the  local  library  to  the  uaar. 

*/ 

/• 

mebuildLXB_vlev_ramote_libraxy  ( eRemoteLibrary) . 

*/ 

/* 

--  Print*  out  tha  liating  of  tba  givan  remote  library. 

V 

/* 

mabuildLXB_lisk_library  ( eRamotaLlbrary ) 

*/ 

/* 

—  Would  add  RemoteLibrary  to  tba  link  liat. 

V 

/* 

aabuildLXB_umlink_library  ( +R*aot*Library ) 

•/ 

/* 

/t 

—  would  raaova  KaaotaLibrary  from  tba  link  liat. 

•/ 

•  / 

/* 

LIBRARY  CLASS  XMTRY  MANAGEMENT! 

/ 

V 

/• 

(COMMAND  INVOKED) i 

•/ 

/* 

nabulldLXB_load_cla*s ( eClaas ) 

*/ 

/• 

--  Zaqporta  a  olaaa  dafinition  fila  from  tba  library i  including  all 

*/ 

/• 

claaaaa  in  tba  dapandanciaa  liat. 

•/ 

/* 

a*buildLIB_aav*_claaa ( eClass) 

•/ 

/* 

—  Sava  tba  claaa  to  diak  and  updataa  tba  library  fila. 

*/ 

/* 

(EXPORTED  TO  CLASS  BSPZMXTXON  MODULI  AND/OR  OSES  HERE) i 

V 

/• 

aabuildLIB_ia_a_locally_daf  in*d_cl**»  ( -fClaaa) 

*/ 

/* 

--  succaada  if  ClaaaNama  axiata  aa  a  claaa  in  tba  local  library. 

•/ 

/* 

mabuildLIB_craata_library_elaaa_antry ( eclaas ) 

*/ 

/* 

—  Craataa  an  antry  for  Claaa  in  tba  library. 

*/ 

/• 

aebuildI.XB_deleta_library_cla*s_entry  ( +Cla»# ) 

*/ 

/* 

--  Narka  a  claaa  aa  dalatad. 

*/ 

/* 

mebuildLIB_undaleta_library_elaas_antry  ( +cl»»» ) 

*/ 

/* 

--  Dnmarks  a  dalatad  elaaa. 

*/ 

/* 

mabuildLXB_purga_library_claaa_antry  ( *Claaa ) 

*/ 

/* 

—  Permanently  ramovad  tba  elaaa  from  tba  library. 

*/ 

/* 

mabuildLXB_chack_load_elaaa  (-tClaaa) 

*/ 

/*• 

--  Xa^orta  a  claaa  dafinition  only  if  it  ian't  already  loaded. 

•/ 

/« 

mebuildLIB_gat_loadad_cla*aaa ( -Claaaaa ) 

•/ 

/* 

—  Return*  a  liat  of  all  claaaaa  currently  loaded  in  memory. 

*/ 

/* 

mebuildLXB_ehack_*av*_cl*s*  (eclas*) 

*/ 

/* 

—  Sava*  a  claaa  dafinition  only  if  it  ia  modified  in  memory. 

*/ 

/* 

m*buildLIB_viaw_library_cla**_entry ( +C1**» ) 

•/ 

/* 

--  Pretty  print*  tha  claaa1  antry  regarding  ita  file  location,  data 

•/ 

/• 

time  a tamp  of  laat  aave,  and  ita  dependency  information. 

•/ 

/• 

mabuildLXB_mark_library_claaa ( eClass) 

*/ 

/• 

—  Seta  the  dirty  flag  on  tha  olaaa1  antry  *o  that  initialise  and 

*7 

/* 

ahutdovn  can  anaura  tha  uaar  baa  a  chance  to  aave  changes. 

*/ 

/* 

msbulldLXB_s*t_llbraxy_olas*_d*pandency  ( tClaaa , eNawDapandant ) 

*/ 

/* 

m*buildLIB_r*mov*_library_cla»»_dependency(+Cla»», eOldXMpandant) 

*/ 

/* 

it 

—  Seta  and  remove*  a  class  from  the  dependency  list  of  another  class. 

•/ 

/ 

/* 

LIBRARY  TASK  ENTRY  MANAGEMENT: 

*  / 

•/ 

/• 

(COMMAND  INVOKED)  i 

•/ 

/• 

mabuildLIB_load_t ask ( eTask ) 

*/ 

/* 

—  import*  a  task  definition  fila  from  the  library,  including  all 

*/ 

/• 

classes  and  task*  in  tba  dapandanciaa  list. 

*/ 

/• 

mabuildhlB_sav*_t*tk ( eTask ) 

•/ 

/* 

--  Sava  tba  task  to  diak  and  updataa  tba  library  fila. 

*/ 

/* 

(EXPORTED  TO  CLASS  DK7XNITI0N  MODULE  AMD/OR  USES  HERB) I 

•7 

/* 

mabuildLXB_ia_a_lesally_deflned_taak(+Taak) 

•/ 

/* 

—  Succaada  ia  TaskNama  exist*  as  a  taak  in  tba  local  library. 

•/ 

/* 

aabuildLXB_eraata_library_task_entry(eTeak) 

•/ 

/* 

--  creates  an  antry  for  Task  in  tba  library. 

•/ 

/* 

mebulldLXB_d*late_llbraxy_taak_*ntry(*Ta*k) 

•/ 

/• 

—  Mark*  a  taak  aa  delated. 

*/ 

/• 

mabuildLXB_undelate_libraxy_task_entry  ( eTask) 

•/ 

/* 

—  unmark*  a  dalatad  taak. 

•/ 

/* 

*obuildLXB_purge_library_task_*nt  ry  ( eTaak ) 

*/ 

/* 

--  Permanently  ramovad  tba  taak  from  tha  library. 

•/ 

/* 

mabuildLXB_cheek_load_task ( eTaak ) 

*/ 
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—  Imports  a  task  definition  only  if  It  isn’t  already  loaded. 
»eh»illdLIB_jet_lo«ded_t«»)f  ( -Tasks  > 

—  Returns  a  list  o£  all  tasks  currently  loaded  in  senary. 
nebUlldLIB_chack_sava_task  ( 4-Task) 

—  Imports  a  task  definition  only  if  it  has  been  modified. 
mebmildLXB_query_save_vorkinc_t ask ( +Task ) 

—  Zf  the  task  is  "dirty",  then  it  queries  the  user  if  it  is  to  be 
saved  to  disk  before  proceeding, 
mabui  ldLIB_yiew_l  ibr  ary_t  ask_antry  ( +Taek ) 

—  Pretty  prints  library  task  information  regarding  its  file  location, 
ins  data  time  steep,  and  its  dependency  information. 
nabuildHB.j>arhwllbrary..taak  ( +Tcek ) 

--  dots  the  dirty  flag  on  the  task's  entry  so  that  initialise 
and  shutdown  can  ensure  the  user  has  a  chance  to  save  changes. 
msbuildUB_task_is_outdatad  ( +Tesk ) 

--  Performs  a  date  cheek  on  all  dependent  entities  to  ensure  that  the 
task  is  based  on  the  most  up  to  date  information.  Zf  a  task  os 
elass  has  been  updated  since  the  last  save  of  the  task,  then  the 
task  is  considered  untrustworthy. 
mabuildLIB_aet_library_t ask_dependency ( +Tesk , eMewDependent ) 
mebuildLlB_remove_libraxy_task_dependency  ( +Task,  eoldDapendent ) 

—  flats  and  remove*  a  class  or  task  from  the  dependency  list  of  the 
task. 

LIBRARY  LISBON  XNTRT  MAHAOXKXNTi 

(coswAim  invoked)  > 
mebuildLXB_load_lesson  ( +  Lesson) 

—  imports  a  lesson  definition  file  from  the  library,  including  all 
classas  and  tasks  in  the  dependencies  list. 

mebuildLXB_eave_lesson( + Lesson) 

—  Save  the  lesson  to  disk  and  updates  the  library  file. 

(EXPORTED  TO  CLASS  DBFIMZTIOH  MODULI  AND/OR  USSD  BIRD  I 
mebulldLXB_is_a_locally_det inedLlasson ( + Lesson) 

—  Succeeds  is  LessonName  exists  as  a  lesson  in  the  local  library. 
mebuildLlB_creato_libraxy_lessoA_entxy  ( +  Lesson) 

—  Creates  an  entry  for  Lesson  in  the  library. 
FMbmlldLZB_dalete_librery_leaeonL.ontxy(+Lessoa) 

—  Marks  a  lesson  as  deleted. 
mebulldLIB_undalete_llbrary_lesson_entryULesson) 

—  Unnarks  a  deleted  lesson. 
nebuildLXB_purge_libr  ary_.lt  sson_entry  ( +  Lesson) 

—  Permanently  removed  the  lesson  from  the  library. 
mabuildLXB_cheek_load_lesson ( + Lesson) 

—  imports  a  lesson  definition  only  if  it  isn't  already  loaded. 
matmlldLIR  oet  loaded  lessons ( -Lessons ) 

—  Returns  a  list  of  all  lessons  currently  loaded  in  memory. 
mabulldLXB_query_save_working_lasson ( + Las son) 

—  Zf  the  lesson  is  "dirty",  than  it  quarias  the  ussr  if  it  is  to  be 
saved  to  disk  before  proceeding. 
mebmildLXB_view_llbraxy_leeson_eatry(+Lesson) 

—  Pretty  prints  library  lesson  Information  regarding  its  file  location, 
its  data  time  stamp,  and  its  dependency  information. 
mabuildbXB_Mrk_llbrary_lesson  ( t  Lesson) 

—  Bets  the  dirty  flag  cm  the  lesson's  entry  so  that  initialise 
and  shutdown  can  ensure  the  user  has  a  chance  to  save  changes. 
mabulldhTB_marh_ocmpilatioa(+bsason) 

—  flats  the  noncurrent  flag  on  the  lesson's  compilation  entry  so  that 
MIBuildor  will  knew  that  the  lesson  must  be  recompiled  before 
executing  certain  lesson-related  comuads. 

mebuildLZB_mark_successf ul.ecmpilat ion ( + Lesson) 

—  Informs  the  library  that  Lesson  has  successfully  compiled  and  the 
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currant  c oscillation  raaldaa  in  assnry  ■  */ 

mabuildLIB_lssson_is_outd»t»d( +Lesson)  */ 

—  Performs  a  data  check  on  all  dependent  antitiaa  to  anaura  that  tha  */ 

laaaoa  is  basad  on  tha  Boat  up  to  data  information,  if  a  task  or  */ 

elass  has  baan  updated  since  tha  last  sava  of  tha  lesson,  than  tha  V 
lasson  is  oonsidarad  untrustworthy.  V 

nebuildLIB_ccmrilation_is_ciirrent  (+Lesaon)  */ 

—  Performs  a  query  on  whether  tha  compilation  is  currant.  */ 

nebuildLXB_set_librery_leason_dapendancy  ( +Lesson,  class  I  task,  eNawDapendent )  *  / 
BabuildLXS_rasK>va_librazy_lasson_dapandancy ( + Lesson, elass I  task,  •/ 

eOldSependent )  * / 

—  data  and  r amoves  a  elass  or  task  frost  tha  dependency  list  of  tha  */ 

laason.  */ 

BabuildLI*_flat_coopilation_f ile_nnne t+Lasson, -Filename)  •/ 

--  Returns  tha  standard  file  name  for  the  coop  Had  Lasson.  •/ 

mabuildLIB_aet_ccepil-»d_lessons ( -CcapiladLassons)  »/ 

—  Returns  all  loadsd  lessons  whose  conciliations  are  currant.  •/ 

*/ 

. . ................................I..../ 
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TAB  7.  METUTOR  VERSION  29  SOURCE 


/*  Keans -Bnda  Tutoring  Platform  --  Version  3$  (KB TO TOR) 

/*  Original  and  versions  1  through  3?  written  by  Professor  hove 
/*  Version  29  and  39  (KBBuildsr  interface  version)  —  by  Ten  oalvin 
. . . . * . ***** . . . 

/* 

/*  KBTutor  program  provides  problem- independent  code  for  performing 
/•  means* ends  tutoring i  tutoring  for  learning  of  sequences  modalable  by 
/•  means -ends  analysis.  This  version  for  Quintus  Prolog  3.0  and  works 
/•  with  graphics  interfaces. 

/* 

/*  Version  29  takes  the  following  facts  produced  by  MBBuilder  compiled 
/*  lessons  and  runs  the  lesson.  HOTli  ‘ill*  the  below  facts  are  compiled 
/*  using  dynamic  modules  --  so  the  module  name  mist  be  used  to  access  all 
/•  the  below  facts  except  for  those  in  the  nr  Tutor  environment. 

/* 

/•  The  concept  of  the  student's  role  still  has  to  be  programmed  in,  as 
/•  the  present  example  simply  handles  the  case  where  the  student  subsumes 
/*  the  null  agent  argument.  Ninos  fix  to  bring  it  in  line  with  the  rest 
/*  the  MBBuilder  system. 

/• 

/*  KBTutor  version  29  uses  a  workbook-like  structure  where  the  student 
/*  enters  the  lesson  «"■<  the  lesson  contains  various  problems  or  exercises 
/•  which  he  needs  to  do.  Currently,  version  29  only  provides  navigational 
/*  frameworks  in  which  a  student  can  simply  run  any  problem  at  will  and  no 
/•  data  about  completion  or  non-completion  of  the  problems  are  retained. 

/*  Among  the  items  needed  in  future  arai 

/•  —  Student  progress  management.  Finish  problem  1  before  going  on, 

/*  for  example. 

/*  —  Course  of  instruction  modeling,  finish  the  lesson  —  or  master 

/•  the  material  —  and  link  into  a  new  lesson. 

/*  —  Student  modeling.  Beginners  vs.  Bxperts 

/• 

,**•**••*••«*.*•••**********•••••***•* 
/•  KBTutor ' s  Basic  Lesson  Data  Structure 

. * 

/* 

/•  KBTutor  lessonr  contain  several  problems  whieh  are  based  on  iden- 
/«  tical  sets  of  basic  means-ends  facts.  In  order  to  save  database  space, 
/*  the  lesson  is  stored  primarily  in  macro  form  wherever  possible.  The 
/*  lesson  is  then  macro-expanded  into  a  problem  module  based  on  the  spec- 
/•  if ic  domains  associated  with  the  problem.  The  lesson  compiler  module 
/*  has  a  full  description  of  tha  macro  oondansad  version  of  the  meane-ende 
/*  database. 

/• 

t*  These  are  the  facts  that  are  net  condensed  —  therefore  not  macro 
/*  expanded  during  problem  initialisation. 

/• 

/*  lesson  (<nama>) . 

/*  dimply  a  tag  name  for  tbe  lesson  used  during  tbs  welcome  section. 

/• 


*/ 

*/ 

*/ 

*/ 

V 
•/ 
*/ 

V 
•/ 

V 

V 

V 
*/ 
*/ 

V 
*/ 
*/ 

V 
*/ 
*/ 
*/ 

V 
*/ 
•/ 
*/ 
*/ 
*/ 
*/ 
*/ 
*/ 
*/ 
•/ 
*/ 

V 
•/ 
•/ 

V 
•/ 
*/ 
*/ 
•/ 
*/ 
*/ 
*/ 
•/ 
*/ 
*/ 
*/ 
•/ 

V 
*/ 


/*  lasson_intro(«text>) .  */ 

/*  Prolog  fact  buffer  which  contains  lessen  introductory  text  for  tha  V 


/•  student.  */ 
/*  *' 
/*  problem ( <nuntoer>, «name>, <atudant  role>) .  */ 
/•  Provides  a  tag  name  for  tha  problem.  */ 
/*  *' 


V 


/* 

problem-intro  («numbar?,<text?) . 

*/ 

/• 

Prolog  fact  but far  which  contains  problem  introductory  text  for  tha 

*/ 

/• 

student. 

V 

/« 

V 

/• 

problem, dome  in ( <numbar? , < domain? , < range? ) . 

V 

/* 

Dead  to  specify  tha  particular  alamants  of  a  domain  for  a  partic- 

V 

/* 

ular  problem. 

V 

/• 

•/ 

/• 

/* 

MSTutor'a  Macro  Ixpandad  Problem  Data  Structure 

V 

*/ 

The  following  ut  tha  fact*  that  ara  macro-expanded  into  tha  prob¬ 
lem  module  for  uaa  is  tha  actual  Ml Tutor  aaasioa.  rha  < agent?  argument 
la  “etudent"  for  thoaa  facta  that  ara  related  to  tha  atudant'a  procaaa. 
Tha  macro  tow  and  tha  expanded  fonaa  ara  given  for  aach. 

rXOSLKM-aPICZl’XC  MSTUTOR  TACTS ! 

Macro i  atart_atata_t  (<problaa  number? , <tenplete? , <mecro  atart>) . 

lap and i  etart_state(< start  atata>) . 

Provide*  tha  apacifie  problem's  initial  condition*. 

Macro i  goal_t  ( <problam  number?,  <agent?,<tenij>late?,<macro  goal?). 
Ixpend;  goal  ( < agent  ? ,  <goal? ) . 

Macro i  goal_t(<problem  number?,  < template?,  <macro  goal>)  . 

Ixpend i  goal(<goal>) . 

Diets  of  propartiaa  which  corraapond  to  tha  atarting  conditions  and 
objectives  provided  via  HSPuild  for  whan  tha  student  or  agent's 
task  la  coop  la tad. 

Macro i  glubal_t(<problem  number?, <taaplats?, <macro  goal>) . 

Ixpend ■  en4_of_problem(<goal?) . 

This  defines  whan  tha  simulation  «nda.  Zt  is  not  required,  and  if 
it  is  omitted,  than  tha  problem  ends  whan  tha  student's  goal  has 
bean  reached,  Zf  an  explicit  global.t  fact  exists,  than  avan  if 
tha  student's  goal  is  couplet ad,  the  simulation  will  continue.  Tha 
actual  and  is  achieved  when  both  tha  global_t  condition  and  tha 
student's  goal  conditions  arc  achieved. 

tIOlDSM  NON-8FICXFZC  MUM-MUDS  FACTS  i 

Macro i  r*coB*a*nd*d_t (<rola> , < templet*? , <macro  diffaranca>, 

<macro  operator?) , 

Ixpandt  racowswndad ( <agant> , <dlf ferenca? , <  operator?) . 

Gives  an  operator  raccssaadad  to  a  achieve  a  particular  sat  of 
facts  different  from  tha  currant  state;  conditionlist  ara  facta 
that  must  be  present  in  tha  currant  stata. 

Macro;  precondition^ («role>,<teaplata>,«macro  operator?, 

< macro  ee" text? , <nacro  precondition?). 

Expand  i  precondition(<ag*nt?,<oparator?, «eontaxt?, precondition?) . 
oivaa  facts  required  by  operator  in  order  to  be  uaad.  Tha  <eontext 
list  describes  unique  conditions  under  which  various  prsconditions 
may  hold. 

Macro;  addpo»tcondition_t (<role>, < templet e>,<macro  operator?, 

ameero  context?, <saero  add  list?). 

BXpand;  addposteondition(<agant?,<opsrator?, <contsxt?,<add  list?). 
Gives  facts  added  by  the  application  of  the  operator.  <context> 
has  same  meaning  as  for  precondition. 
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/• 

/*  Macro i  daletepo*teoadition_t (<rol#», (template*,  <Mcro  operator*, 

/•  (macro  context* , <macro  delete  Hat*). 

/•  Ixpandi  deleteposteondltlon(<agent*, (operator*, (eontext*, 

/*  (delate  lift*), 

/•  olvee  facta  delated  acd  added  by  the  application  of  the  operation. 
/•  < context  liat  haa  the  same  meaning  aa  for  precondition. 

/* 

/>  tdto*  anttoRTnra  pacts. 

/* 

/*  Macro i  slngular_t(  (tablets*,  <smoro  object*) . 

/ *  Macro  t  plural_t ( (template* , < macro  ob j act » ) . 

I*  Ixpandi  singular («objeat>) . 

/*  Ixpandi  plural ((Object*) . 

/*  Head  to  override  the  defaulta  concerning  the  conjugation  of  the 

/•  verb  "to  be"  for  those  objects  whose  name  doesn't  follow  atandard 

/*  plural it at ion. 

/* 

/•  Macro:  randcbange_t ((template*, {(macro  operator  spec*), 

/*  < macro  context*,  <macro  delete*,  < macro  add*, 

/*  <probebiiity  of  occurrence* , (macro  text*). 

/•  ixpandi  randchange( (<operator  spec*) .(context*, (delate*, <edd>, 

/*  (probability  of  occurrence*, (text*) . 

/*  Defines  random  events  that  are  triggered  by  (operator*  under  the 
/*  conditions  defined  in  (context*,  or  are  a  random  initial  condition 
/"  of  the  problem  as  defined  by  "init".  (probability  of  occurrence* 

/*  is  a  value  from  0.0  to  1.0  which  describee  the  chances  of  the 
/*  event  taking  place  given  that  the  context  is  awt.  (delete  facts* 

/*  and  (add  faota*  are  similar  to  that  of  the  postcondition  proaaas. 
t*  (message  to  student*  is  only  printed  in  the  event  occurs.  The 
/*  (context*,  (delete  facts*,  and  (add  facts*  may  be  empty. 

/•  (macro  operator  epeo*  is  one  of  (macro  operator*,  any_op,  init, 

/*  or  init ((problem  number*),  (operator  spec*  is  one  of  operator, 

/*  any_op,  or  init.  "init"  and  "init (problem  number)"  refer  to  ran- 
/*  don  atarc  state  information.  "aay_ep"  refer  to  random  changes 
/*  that  occur  regardless  of  the  operator  used  (the  discriminating 
/*  factor  thus  la  the  context) . 

/* 

/•  LISSOM  DISPLAY  PACTS  (TUT  XMTHPACI)  i 

/*  MOTIt  See  graphics flag  below.  Theae  facta  are  used  when  grephicsflag 
i*  is  not  set. 

/" 

/*  Macro i  apply_text_t( (template*, (macro  operator* , (macro  context*, 

/*  (macro  text*) . 

/*  Ixpandi  apply_text((operator*,(aoatext>,(taxt>) . 

/*  The  (text*  is  printed  to  the  user  whenever  the  given  <operetor*  is 

/•  applied  under  the  context  of  (context  list*.  These  are  directly 

/*  aligned  with  the  addpostcondltlon  facte. 

/* 

/*  MOTES  OK  UMPLATISi 

/*  The  (template*  can  contain  clanantc  of  any  of  tha  following  format 
/•  (domain*  --  which  expands  to  ons  element  of  a  domain. 

/*  acme ((domain*)  --  same  as  (domain*. 

/•  forallt (domain*)  —  expands  to  all  members  of  ths  domain. 

/*  Tha  "seme"  and  "for all"  quantifiers  are  somewhat  misleading  in  that 
/*  they  really  mean  "any"  and  "all". 

/• 

/• 

/* 

/*  L1SP0M  DISPLAY  PACTS  (SIAPIICI  ZHTIIPACI) i 

/*  Currently  tha  graphies  interface  is  not  usable  since  megraph  is  eat 


/ 

/ 

/ 

/ 

/ 

/ 

/ 

t 

/ 

/ 

V 
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/•  Cor  Imisu  compiled  la  module  user  --  not  la  a  dynamically  •/ 
/*  compiled  module.  */ 
/•  •/ 
/•  graphiosf lag.  */ 
/•  Activates  KSTutor'e  graphical  interface.  */ 
/•  •/ 
/•  mooolorflag.  */ 
/*  Operates  black/white  oa  a  color  tarmlaal.  */ 
/•  •/ 
/*  bmap<efeet>,  < conditions* ,  epicture-filename*,  ex-coordinate*,  */ 
/*  ey-eoordinate>,  ewidth* ,  eheight*.  lecolor*!).  */ 
/*  Xf  graphical lag  aat,  givaa  the  nan*  of  a  file  holding  a  bitmap  •/ 
/*  portraying  tha  givaa  faet  whan  tha  condi tloaa  hold*  coordinator  ara  */ 
/*  uppar  latt  eoraar  of  place  wharo  bitmap  la  putt  width  and  bright  */ 
/*  ara  tha  aiaa  of  tha  bitmap.  Bitmap*  ara  optional  for  a  fact,  and  •/ 
/•  thara  can  ba  multiple  bitmap*  all  diaplayad  tor  tha  aama  tact.  */ 
/•  */ 
/*  tort  (<f act >.  < conditions,  <taxt-*trlng>,  <z-coordin*ta>,  •/ 
/■  ey-coordinata* ) .  */ 
/*  Xf  graphieaflag  aat,  and  context  applla*,  write*  that  text  at  that  */ 
/•  place  on  tha  acraan  •/ 
/•  */ 
/•  MBTUTOA  CACUS  I  ACTS  t  •/ 
/*  Tha a a  facta  are  cached  by  lasaon.  V 
/•  •/ 
/•  top_goel(<geal>) ,  */ 
/*  Same  aa  tha  goal  fact.  Cachad  par  laaaon.  */ 
/•  V 
/*  top_aolution(<li*t  of  operators).  */ 
/*  Thio  is  a  liat  of  operator*  which  MITutor  baa  determined  la  tha  */ 
t*  moat  direct  solution.  Cached  par  laaaon.  */ 
/*  •/ 
/*  current_stete( estate*) .  •/ 
t*  hist  of  propart ia»  which  indicate  the  present  aituation.  •/ 
/•  «/ 
/*  laat_*tata(<etata>) .  */ 
/*  Tha  pravioua  valve  of  eurrent_state/l,  */ 
/*  •/ 
/*  op_list (eglobal  Hat  of  operators*),  *  1 
/*  Thia  la  a  liat  of  all  tha  oparatora  available  In  tbs  laaaon.  •/ 
/•  */ 
/*  solution (eagent*,  <atata>,  egoal*,  eoplist*,  egoal  atata>) .  */ 
/*  This  la  a  oaebad  solution  to  a  subproblem  of  tha  laaaon.  Dead  to  */ 
/*  a eve  time  In  tha  calculation  of  fueura  solutions.  */ 
/*  •/ 
/*  un»olvable(eagent>, estate*, egoal*) .  */ 
/•  Indicates  that  egoal*  cannot  ba  reached  from  <atate>  by  eegent* .  •/ 
/•  Uaed  to  save  time  againat  computing  known  unsolvable  problems.  */ 
/•  */ 
/*  s**sion_num(en>) .  */ 
/*  Thia  is  tba  nth  run  that  tha  student  has  started.  (Counter  which  */ 
/»  ia  maintained  in  the  Prolog  utilities  coda.  •/ 
/•  */ 
/*  error_nun(<n>) .  */ 
/*  The  student  has  cousaittad  n-1  errors  during  tha  nth  sesalon.  (Also  */ 
/*  a  counter  which  ia  maintained  in  tha  Prolog  Utilities  coda.  V 
/•  */ 
/*  atudant_arror (eaassion  number >,  < error  nuabar>i  < student  operator*,  V 
/*  etutor  chosen  operator*,  estate*,  egoal*) .  */ 
/•  Stores  tba  information  about  tba  nth  error  in  the  mtb  session.  Tba  V 
/•  estate*  and  egoal*  ara  tba  currant_stata  and  tbs  laaaon  objectives ,  •/ 
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/•  «kil«  .etudent  operator >  indicate.  Ui  atudant ' ■  choice  of  operator  V 

/*  and  .tutor  choaan  operators  waa  the  preferred  choice  by  K*  Tutor.  •/ 

/•  •/ 

/•  tamo*  nrvinoMaMT  fxctii  */ 

/•  •/ 

/•  dabugf lag.  •/ 

/*  If  aaaartad,  debugging  info  la  printed  during  Mas* -and*  analysis  */ 

/•  •/ 

/•  atudentfleg.  •/ 

/*  If  aaaartad,  does  sot  print  info  oa  poaalbla  taaohar  arrora.  Thia  */ 

/•  flag  abould  ba  aat  whan  tha  atudant  la  ru&birg  tba  prograa.  (Tba  */ 

/*  flag  la  aat  automatically  whan  MUulldar  la  rubbing.  */ 

/•  */ 

/•  atop_tlma(<tlms>) .  •/ 

/•  May  wait  indicator .  Tails  tba  atudant  “X  aat  thinking..."  during  •/ 

/*  extended  parioda  of  oaloulatlon.  •/ 

/•  */ 

/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/ 

/a  Uportad  pradleataa  */ 

/•  »/ 

/*  rub_leasoa/ruii_leaaon(<Lasson>) .  •/ 

/*  Kuna  tha  laaaon  loaded  Into  tha  dynamic  nodule  .lesson  nodule >.  */ 

/•  'uaar1  la  assumed  If  tha  argument  la  laft  off.  (BXtlTi  HXVKK  uaa  •/ 

/*  'uaar'.  klways  uaa  a  dynamic  nodule  in  order  to  prevent  problems  •/ 

/•  regarding  dynamic  aa a art ion*  and  abolishments. )  */ 

/*  Tor  tha  graphics  interface,  you  must  have  tha  laaaon  in  tha  uaar  */ 

/•  module  in  Prolog  and  MOST  use  tha  non-argument  run-leseon.  (Thia  */ 

/*  will  ba  oorraatad  eventually.)  •/ 

/•  •/ 

/.........a*.... . . . . . . 
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APPENDIX  B.  MEBUILDER  USER’S  MANUAL 


The  manual,  minus  appendices,  enclosed  here  is  rhe  same  one  provided  to  the  students 
in  the  experiment  discussed  in  Chapter  VI.  The  following  are  the  sections  of  the  manual: 

Tab  1.  Introduction 

Tab  2.  MEBuilder’s  Interface  and  Environment 

Tab  3.  Library  Facilities 
Tab  4.  Step  One  --  Designing  an  Object 

Tab  5.  Step  Two  --  Designing  a  Task 

Tab  6.  Step  Three  -  Designing  a  Lesson 
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TAB  1.  INTRODUCTION 


1.  General. 

a.  About  the  Manual.  This  user's  manual  is  the  first  draft  for  the  MEBuilder  lesson  authoring 
system  for  METutor,  specifically  written  for  lab  experimental  purposes.  It  currently  provides  only  a  basic 
introduction  to  MEBuilder  data  structures  and  a  reference  guide  for  commands  for  the  version  dated  31 
August  1994.  Comments  and  suggestions  are  welcome. 

b.  Files .  MEBuilder  is  a  lesson  authoring  system  written  for  METutor  versions  29  and  beyond. 
li  is  released  in  executable  form  and  is  available  in  the  file  -galvInt/mebulld/MEBuikler.  You  are  free  to 
copy  the  file  into  your  own  directory  to  use  (it  is  about  1.6MB  large).  Please  do  not  run  MEBuilder  in  the 
gatvtnt  directory.  You  must  run  it  in  from  your  directory  otherwise  MEBuilder  will  not  be  able  to  write  to 
the  library  file.  Similarly,  METutor  is  available  from  '•galvint/mebuHd/METutor. 

2.  Snecial  Features  of  MEBuilder. 

a.  Library.  In  the  directory  you  are  using,  MEBuilder  will  set  up  a  local  library  directory  in  Alb. 
In  this  directory  will  be  all  the  data  files  of  the  lesson  material  you  will  produce.  The  directory  will 
contain  a  special  file,  called  mebuild.lib  which  contains  data  on  all  the  files  in  the  directory.  Please  do  not 
use  Jl lb  for  any  purpose  other  than  MEBuilder  sessions. 

b.  METutor  Interface.  METutor  is  directly  accessible  from  within  MEBuilder  using  the  run 
lesson  command.  This  allows  you  to  test  a  completed  lesson  without  having  to  run  a  separate  METutor 
session. 

c.  Object-Oriented  Structures.  MEBuilder  uses  an  object-oriented  system  which  allows  you  to  re¬ 
use  objects  you  create  for  use  in  multiple  lessons.  MEBuilder  employs  both  generalization  and 
aggregation  principles  along  with  pait-kind  inheritance.  Single  inheritance  is  the  only  type  permitted, 
however. 

3.  Tfrfic-UYcrcd  Lesson  Design- 

When  designing  a  lesson,  you  will  do  so  in  three  steps.  MEBuilder  lesson  material  is  constructed 
using  a  "bottom-up"  approach  -  meaning  that  you  will  start  at  the  lowest  level  and  end  with  tne  overall 
lesson.  This  bottom-up  approach  will  be  replaced  in  future  versions  with  a  more  top-down  approach. 

a.  Design  the  objects.  Objects  are  the  props  and  characters  that  the  student  will  manipulate  in  the 
lesson.  The  student  will  describe  the  basic  properties  of  the  object  and  its  behaviour. 

b.  Design  the  tasks.  A  task  is  a  sequence  of  operations  that  take  the  student  from  some  given 
condition  to  a  specific  goal. 

c.  Design  the  overall  lesson.  A  lesson  is  a  workbook  of  exercises.  In  each  exercise,  you  will 
describe  a  scenario  for  the  student  and  the  goals  that  the  student  must  achieve  based  on  the  tasks. 
Exercises  may  increase  in  scope  or  difficulty. 

4.  I  avnnt  of  this  Manual. 
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The  manual  is  broken  into  five  main  sections  «■  one  for  the  MEBuitder  user  interface,  one  for  the 
library  and  one  for  each  of  the  above  lesson  design  steps.  Each  section  contains  a  reference  listing  of  the 
available  commands  along  with  some  examples  of  the  commands  in  use.  For  additional  help,  you  may  use 
the  help  command  in  MEBuilder.  Appendix  1  contains  a  complete  command  reference.  Appendix  2 
contains  a  documented  script  run  which  takes  you  through  all  the  fundamental  steps  for  constructing  a 
simple  preflight  tutor. 
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TAB  2.  MEBUILDER’S  INTERFACE  AND  ENVIRONMENT 


1.  CMimana  Line  Format 

MEBuilder  is  presently  a  pure  character-based  interface,  which  means  that  all  inputs  are  from  the 
keyboard  and  at  present  there  is  little  support  for  graphics.  The  commands  are  one  or  two  words  long,  and 
many  have  parameters  which  must  be  supplied. 

In  the  appendix,  you  will  note  that  the  commands  are  listed  in  bold  italics  and  arguments  are 
listed  in  brackets.  These  are  arguments  which  MEBuilder  must  have  in  order  to  process  the  command, 
however  you  have  the  choice  of  supplying  them  on  the  command  tine  or  specifying  them  when  MEBuilder 
responds  with  a  query.  For  example,  the  load  object  command  takes  a  single  parameter,  that  of  named 
<object>.  You  may  invoke  the  command  in  the  following  ways: 

MEBUILD>load  object  named  my  object 
-or- 

MEBUILD>load  object 

Load  which  object?my  object 

Important  Note :  At  any  time  while  a  command  is  invoked  and  you  are  being  asked  a  question, 
you  can  return  to  the  prompt  by  typing  abort. 

2.  MEBuildcr's Command, Loop  Hierarchy- 

MEBuilder’s  user  interface  is  divided  into  four  main  loops.  Upon  executing  MEBuilder,  you 
enter  the  Main  lamp.  Certain  commands  access  the  other  loops.  In  order  to  pop  out  of  a  given  loop,  you 
use  the  quit  command.  Using  quit  from  the  Main  Loop  exits  MEBuilder. 

a.  Main  Loop.  The  Main  Loop  represen's  the  highest  level  interface  command  loop  provided 
by  MEBuilder.  It  provides  access  to  MEBuilder’s  library  functions  and  access  to  MEBuilder's  object 
definition  commands.  The  library  functions  include  loading  and  saving  commands  for  objects,  tasks  and 
lessons.  The  object  definition  commands  include  those  that  create  and  manipulate  the  object  data  structure. 

The  Main  Loop  prompt  is  MEBU1LD>. 

b.  Task  Loop.  The  task  loop  provides  all  of  the  commands  to  the  user  for  defining  and 
manipulating  tasks.  The  r.-.ck  loop  also  imports  various  view  commands  from  the  main  loop  for  classes  and 
the  library  so  the 

user  may  query  information  about  them.  The  task  loop  is  invoked  with  one  and  only  one  task.  This  means 
that  if  you  wish  to  woik  on  a  different  task,  you  must  exit  the  task  loop  using  the  quit  command  and 
reinvoke  the  loop  with  die  desired  task. 

The  task  loop's  prompt  is  [TASKirarfc  name]>  where  the  task  being  wotked  on  is  in 
plrce  of  task  name.  The  task  loop  is  accessed  via  the  create  task  and  work  on  task  commands. 

c.  Lesson  Loop.  The  lesson  loop  provides  all  of  the  commands  to  the  user  for  defining  and 
manipulating  lessons.  The  lesson  loop  also  imports  various  view  commands  from  the  main  loop  for 
classes  and  the  library  sc  the  user  may  query  information  about  them.  The  lesson  loop  also  contains  the 
commands  to  access  MF.Tutor. 
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The  lesson  loop  is  invoked  with  one  and  only  one  lesson.  This  means  that  if  you  wish  to 
woik  on  a  different  lesson,  you  must  exit  the  lesson  loop  using  the  quit  command  and  reinvoke  the  loop 
with  the  desired  lesson. 

The  lesson  loop’s  prompt  is  [LESSON:l«ron  name]>  where  the  lesson  being  worked 
on  is  in  place  of  lesson  name.  This  loop  is  accessed  by  the  create  lesson  and  work  on  lesson  commands. 

d.  Problem  Loop.  The  problem  loop  provides  all  of  the  commands  to  the  user  for  defining  and 
manipulating  problems  within  a  lesson.  The  problem  loop  also  imports  various  view  commands  from  the 
lesson  loop  for  classes  and  the  library  so  the  user  may  query  information  about  them. 

The  problem  loop  is  invoked  with  one  and  only  one  problem.  This  means  that  if  you 
wish  to  work  on  a  different  problem,  you  must  exit  the  problem  loop  using  the  quit  command  and  reinvoke 
the  loop  with  the  desired  problem. 

The  problem  loop’s  prompt  is  [PROB -.lesson  nameiproblem  number]>  where  the  lesson 
being  worked  on  is  in  place  of  lesson  name  and  the  index  number  of  the  problem  is  in  place  of  problem 
number.  The  loop  is  accessed  by  the  work  on  problem  command  from  within  the  Lesson  Loop  only. 

3.  Special  Environment  Features  of  MEBuilder. 

a.  Autosave  Capability.  MEBuilder  comes  with  a  built-in  active  autosave  system  which  helps  to 
preserve  the  session  in  case  of  ungraceful  exit  from  MEBuilder.  The  autosave  file  (located  in  the  working 
directory  and  called  autosave.meb)  is  a  pure  database  dump  of  all  work  being  done  with  the  Quintus 
Prolog  dynamic  modules  preserved. 

The  autosave  process  occurs  every  tenth  command  in  the  Main  Loop.  Task  Loop,  Lesson 
Loop,  or  Problem  Loop.  If  a  complex  session  is  taking  place,  this  process  can  be  quite  slow  -  hopefully 
future  implementations  will  provide  ways  of  speeding  it  up. 

The  autosave  frequency  and  the  destination  autosave  name  can  be  set  using  the  set 
autosave  count  and  set  autosave  data  commands.  The  view  autosave  data  command  will  allow  you  to 
view  the  current  autosave  settings. 

To  restore  an  active  session  to  the  point  of  the  last  autosave,  use  the  restore  autosave  file 

command. 


b.  Help  Facility.  At  any  time  in  the  four  main  loops,  you  may  invoked  the  help  facility  by 
selecting  the  help  command.  While  in  the  help  facility,  you  request  information  by  providing  the  name  of 
the  command  or  topic  you  want  at  the  MEBUILD  HELP>  prompt  You  can  get  a  list  of  help  entries  by 
typing  help  inside  the  Help  facility.  The  quit  command  will  return  you  to  where  you  entered  from. 


TAB  3.  LIBRARY  FACILITIES 


1.  intredustiofl- 

MEBuilder  provides  a  basic  library  facility  which  helps  track  all  the  items  created  during 
MEBuilder  sessions  --  objects,  tasks,  lessons,  and  metutor- ready  files.  Items  are  tracked  by  date  last  saved 
and  dependencies.  Item  dependencies  indicate  those  items  that  must  be  in  the  database  in  order  to  use  the 
item  (example  ~  a  task's  dependencies  are  the  objects  involved  in  the  task).  The  tracking  of  dependencies 
is  used  to  auto-load  everything  needed  in  one  stepand  to  ensure  that  changes  in  one  item  don't  damage  all 
other  items  that  depend  on  it. 

The  library  is  stored  in  ,/lib  of  the  working  directory  andit  contains  a  directory  listing  file 
(mebuild.lib)  plus  one  filefor  each  item  (object  files  have  extension  .els,  tasks  ,tsk,lessons  .les,  and 
METutor  files  .met).  The  listing  file  containsone  entry  per  item  indicating  the  name,  file,  etc.  In  future 
implementations,  the  listing  file  will  also  indicatelinks  to  other  MEBuilder  libraries.  This  will  allow 
objects  in  other  directories  to  be  read-accessed  by  items  in  the  local  library. 

2.  Library  Manipulation  and  Viewing  Commands. 

There  are  three  things  you  can  do  with  libraries  -  create  (or  recreate)  one,  view  the  entries  in  one,  or  link 
in  a  new  library.  The  options  with  these  commands  are  currently  very  limited  and  will  be  upgraded  in 
future. 


a.  Clearing  or  resetting  the  library  --  the  create  library  command.  Currently,  MEBuilder  only 
recognizes  './lib'  as  the  library  directory  so  running  this  command  clears  the  library  data  file  and  start' t.  te 
directory  anew.  Be  careful  when  using  this  command  --  be  sure  that  an  MEBuilder  library  does  no;  exist 
(it  will  query  to  continue  if  one  does). 

b.  Viewing  the  Contents  of  the  library  --  the  view  library  command.  This  command  will  provide 
a  by  name  listing  of  all  the  objects  in  the  library  -  which  have  been  loaded  and  which  have  been 
modified.  The  list  is  alphabetized  in  order  by  objects,  tasks,  and  lessons.  (NOTE:  Unfortunately  the  list  is 
not  run  through  more  so  it  will  likely  scroll  the  screen.  For  non-xterm  environments  this  might  cause  a 
problem.  This  feature  is  slated  for  future  improvement). 

c.  Unking  together  and  accessing  remote  library  information  -  the  link  library  command.  This 
command  is  not  yet  implemented.  This  command  will  allow  you  to  access  objects  and  tasks  in  multiple 
libraries.  The  key  difference  is  that  remote  information  is  read-only,  no  library  item  can  be  mutually 
dependent,  and  a  local  definition  of  some  library  item  takes  precedence  over  items  of  the  same  name  in  the 
remote  library. 

d.  Cleaning  out  deleted  information  from  the  library  -  the  purge  library  command.  This 
command  removes  all  entries  from  the  library  that  have  been  marked  for  deletion  by  the  remove  object, 
remove  task,  and  remove  lesson  commands.  (This  command  is  not  yet  implemented.) 

3.  Load  and  Says  Commands. 

Information  about  these  commands  are  available  in  the  reference  section  at  the  back  of  this 
manual  and  are  discussed  in  detail  in  the  other  chapters  of  this  text. 

a.  Discussed  in  Section  C  ( Objects )  --  load  object  and  save  object 
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b.  Discussed  in  Section  D  (Tasks)  -  load  task ,  and  save  task 

c.  Discussed  in  Section  E  (Lessons)  --  load  lesson ,  save  lesson,  and  save  compiled  lesson 
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TAB  4.  STEP  ONE  -  DESIGNING  AN  OBJECT 


1.  What  is  an  Object? 

An  object  is  MEBuilder's  representation  for  any  entity  that  will  exist  in  a  lesson  —  be  it  a  prop  or  a 
character.  The  purpose  of  an  object  is  to  encompass  the  make-up  and  behaviour  of  these  entities  so  they 
may  be  used  in  more  than  one  lesson  and  the  make-up  and  behaviour  is  guaranteed  to  be  consistent. 

Objects  are  abstract  When  you  develop  a  flashlight  object,  for  example,  you  are  defining 
behaviour  true  of  all  flashlights.  This  way,  if  you  declare  a  lesson  to  have  two  flashlights  --  a  black  and  a 
silver  -  the  behaviour  is  consistent  between  the  two. 

Objects  are  represented  as  the  collection  of  data  relating  to  one  ntity.  These  are: 

—  Parent  Object  Information  about  what  type  of  object  it  is. 

—  Components.  Information  about  what  other  objects  comprise  this  object. 

—  Property  Sets.  Information  about  what  states  the  object  can  be  in  and  which  states  are 
mutually  exclusive 

--  Operations.  Information  about  what  operations  can  be  performed  on  the  object  and 
what  behavior  is  exhibited  when  done  so 

--  Summaries.  Ways  of  summarizing  a  collection  of  states  of  an  object  in  one  term 

--  Background  Changes. 

Information  about  behavior  that  an  object  may  exhibit  without  an 
external  stimulus 

The  three  items  above  that  are  required  for  any  object  to  be  used  in  MEBuilder  are  the  parent 
object,  property  sets,  and  operations.  These  three  should  be  identified  in  order. 

2.  The  Object  Hierarchy  -  Defining  the  Parent  Object. 

IMPORTANT  NOTE:  Before  you  declare  a  new  object,  ensure  that  its  parent  (defined  below)  is 
defined  first  and  loaded  into  the  current  MEBuilder  session. 

Parent  objects  are  used  for  specifying  an  object  in  which  a  new  object  shares  data  and  behavior. 
The  parent  object  is  therefore  a  more  general  form  of  the  new  object.  The  opposite  of  parent  object  is 
child  object. 

For  example,  one  may  have  a  prop  type  named  "car".  One  can  then  create  "sedan"  and  "sports 
car"  as  new  objects  based  on  ’car".  "Car"  becomes  the  parent  object  of  "sedan"  and  "sports  car"  -  and  the 
latter  two  inherit  all  the  object  definition  data  that  exists  in  car.  By  "inheriting  data",  we  mean  that  if  a  car 
has  four  wheels  as  components,  then  by  the  parent  object  relationship  sedan  automatically  has  the  four 
wheels  without  you  having  to  repeat  that  information  when  building  a  sedan. 

Parent  objects  can  be  chained,  meaning  that  if  a  "four-door  sedan"  was  created,  it  inherits  all 
information  from  car  and  sedan.  Chained  objects  produce  what  we  refer  to  as  "ancestor/descendant” 
relationships.  "Ancestor/descendant"  can  be  used  in  lieu  of  "parent/child"  as  well. 
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Sedan  can  change  some  information  in  car  also.  For  example,  if  cars  have  an  engine,  perhaps  a 
sedan  has  a  particular  type  of  engine.  So  the  engine  component  can  be  overwritten  by  sedan.  Then  "four- 
door  sedan"  inherits  the  sedan  information  Hrst,  not  the  car  information. 

In  MEBuilder,  every  object  is  a  descendant  of  either  "prop"  or  "character".  The  parent  object  is 
specified  upon  creation  of  the  object,  and  can  be  changed  (This  is  strongly  discouraged  as  it  will  disrupt 
the  behaviour  of  any  task  or  lesson  that  uses  it).  Objects  can  only  have  one  parent. 

The  parent  object  is  specified  when  the  object  is  created  using  the  create  object  command. 
MEBuilder  will  provide  a  list  of  all  the  objects  currently  loaded  in  the  session  plus  the  standard  ones 
"prop"  and  "character".  In  order  to  change  the  parent  object,  you  can  use  the  modify  parent  object 
command. 

3.  Declaring  Compaignis. 

After  the  object  has  been  declared,  the  next  thing  you  should  do  is  declare  any  components  it  may 

have. 


Component,  in  MEBuilder  terms,  is  the  way  of  describing  both  "a  part  of'  and  "has  a" 
relationships  between  objects.  For  example,  walking  robots  have  x  number  of  legs  so  each  leg  is  "a  part 
of'  a  walking  robot.  Or,  a  fire  team  member  might  have  equipment  that  he  would  use  in  a  firefighting 
problem.  Therefore,  the  team  member  "has"  equipment  With  reference  to  characters,  component 
relationships  can  probably  be  better  described  as  "possessive"  relationships  and  the  component  is  the 
character’s  possession.  The  word  possession  is  only  used  here  for  illustrative  purposes  -  component  is 
used  for  both  meanings. 

MEBuilder  allows  you  to  identify  component  relationships  between  objects.  Components  are 
manipulated  via  the  create  component,  remove  component ,  and  modify  component  commands.  Apart 
from  specifying  the  owning  object  and  the  component  object  type,  you  will  need  to  specify: 

--  A  component  name.  For  objects  which  have  one  of  some  type  of  component  (cars  have  one 
engine,  for  ex.)  you  should  use  the  object  name  as  the  component  name.  But,  if  the  object  has  multiples  of 
some  component  (cars  have  four  wheels)  then  the  component  name  must  be  unique  ("left  front  wheel", 
"right  front  wheel”, ..) 

-  The  tense  of  the  component  -  singular  or  plural.  This  ensures  that  the  user  output  is  correct  in 
terms  of  matching  verbs  in  natural  language.  MEBuilder  will  query  the  tense  in  the  form  of  a  question  as 
to  whether  or  not  the  name  follows  the  "ends  in  s"  rule.  In  other  words,  if  it  does  not  end  in  s  it  will 
assume  it  is  singular  and  will  query  whether  its  assumption  is  correct. 

The  view  component  command  will  show  the  entire  definition  of  the  component,  including  its 
inheritance  source  (whether  derived,  inherited  by  parent  object,  or  inherited  by  component). 

4.  DeclarinaiToaeia^sia- 

Property  sets  are  used  to  describe  states  that  an  object  may  be  in  and  the  relationships 
(specifically  mutual  exclusion)  among  these  states.  A  property  set  is  defined  as  a  set  of  properties  that  an 
object  can  only  have  one  of  at  a  given  time.  Examples  of  property  sets: 

-  A  machine  can  be  "on"  or  "off1. 

-  A  streetlight  can  be  "red",  "green",  or  "yellow". 
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-  A  student  can  be  "present"  or  "not  present". 

Property  sets  always  have  a  least  two  elements.  A  set  that  has  one  specified  element  "X"  has  an 
implicit  element  "not  X".  Property  sets  are  described  with  the  following  information,  and  are  manipulate^ 
via  the  create  property  set ,  remove  property  set,  and  modify  property  set  commands. 

--  The  object  being  described. 

--  A  name  which  describes  the  set.  The  above  three  examples  could  be  described  in  order  as 
"switch  position",  "color",  and  "presence".  IMPORTANT:  TV  name  must  be  one  that  can  be  used  in 
natural  language  output  because  phrases  such  as  "object's  color  is  unknnown"  may  be  shown  to  the  student. 

-  The  members  of  the  set  (also  called  the  domain  of  the  set).  Currently,  only  qualitative  members 
are  allowed.  Quantitative  members  might  be  added  at  a  later  time. 

••  Whether  or  not  the  state  of  an  object  is  readily  visible  or  is  something  that  must  be 
discovered.  Examples  include  the  "charge  level"  of  a  battery  -  one  doesn't  know  the  charge  level  just  by 
looking  at  it,  one  must  perform  an  action  to  find  out.  This  translates  into  information  that  a  student  is  told 
he/she  might  not  know  when  running  the  lesson. 

Members  of  property  set  must  be  unique  to  the  object.  For  example,  the  word  "blue”  cannot  be 
used  to  describe  both  "color”  and  "mood".  You  cannot  begin  the  name  of  a  property  with  the  word  not. 
Not  is  a  reserved  word.  If  you  have  a  property  set  which  has  an  x  and  not  x  relationship,  you  must  specify 
only  the  x. 

The  view  object  command  will  only  show  the  name  of  the  member  property  sets.  To  get  the 
complete  detailed  definition  of  the  set,  use  the  view  property  set  command.  The  output  will  also  contain 
the  inheritance  source  (whether  derived,  inherited  by  parent  object,  or  inherited  by  component). 

The  following  are  suggestions  for  the  naming  of  property  set  members.  Although  it  seems 
puerile,  the  best  way  to  name  the  property  set  members  is  to  use  the  closest  adjective  form  of  the  operation 
used.  For  example,  a  door  object  can  be  opened  or  closed.  The  operations  would  be  "open  door"  and 
"close  door".  Similarly,  a  device  that  one  can  install  or  remove  should  be  "installed"  or  "removed".  Even 
though  it  sounds  repetitve,  it  is  easily  for  the  student  to  grasp  the  direct  relationship  between  his  actions 
and  the  result 

S.  Declaring  Operations. 

Ensure  that  you  are  declared  all  of  your  property  sets  first  before  entering  this  step. 

Operations  are  the  primitive  methods  by  which  the  student  or  an  agent  can  manipulate  one  or 
more  objects.  Tasks  and  lessons  consist  of  sequences  of  these  primitives.  The  intent  of  the  operation  is  to 
encapsulate  an  event  that  takes  precisely  one  turn  to  complete.  In  tasks  and  lessons,  operations  defined  at 
the  object  level  are  called  primitive  operations. 

Operations  are  described  with  several  data  items  and  are  managed  via  the  create  operation, 
remove  operation,  and  modify  operation  commands. 

-•  The  direct  object  The  direct  object  is  the  thing  that  is  the  focus  of  the  operation  -  the  primary 
item  being  manipulated.  Can  be  either  a  whole  object  or  a  component  of  an  object. 

--  The  indirect  objects.  These  are  objects  which  must  be  present  in  order  to  do  this  operation. 

-  The  operation  name.  Must  contain  direct  object,  but  may  contain  any  or  all  the  indirect  objects. 

-  The  intended  effect  The  primary  or  desired  change  of  state  in  the  direct  object. 
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••  The  preconditions.  These  are  the  conditions  in  which  the  direct  object  and  indirect  objects 
must  be  in  for  this  action  to  be  allowed 

-•  The  side  effects.  These  are  changes  of  state  that  ary  of  the  objects  also  realize  different  from 
the  intended  effect.  These  side  effects  ‘always*  happen. 

An  example  is  "tighten  the  nut  with  the  wrench"  for  the  object  nut  Nut  is  the  direct  object  and 
wrench  is  an  indirect  object  However,  let's  say  that  bolt  is  also  an  indirect  object  that  is  unspecified  in  the 
operation  name.  The  intended  effect  would  likely  be  that  the  "nut  is  tightened".  The  preconditions  would 
be  that  the  "nut  is  on  the  bolt"  and  "wrench  is  serviceable".  The  side  effects  might  be  that  the  "bolt  is  not 
free". 


It  is  important  to  note  that  the  operation  is  defined  only  in  instances  where  all  the  objects  are 
used  Therefore,  if  a  given  task  only  uses  nuts  and  bolts  but  not  wrenches,  the  above  operation  cannot  be 
used 


The  following  are  the  rales  for  operation  names.  The  examples  above  show  the  pattern  for 
operation  names.  The  operations  follow  the  convention  of  a  verb  phrase,  followed  by  a  direct  object, 
trailed  by  a  set  of  prepositional  phrases  containing  the  indirect  objects.  The  verb  phrase  and  the  direct 
object  are  required  elements  of  the  operation  name.  However,  there  is  one  specnd  case  to  be  aware  of.  If 
the  object  is  a  character,  and  the  direct  object  is  the  character  object  itself  (not  a  possession  of  the 
character),  then  you  should  use  the  special  form  " have  <characU  ~>  < operation  name>".  What  this  will 
do  is  signal  MEBuilder  to  strip  off  the  "have"  phrase  when  compiling  any  lesson  with  it.  This  way,  the 
operation  name  correctly  identifies  the  direct  object  and  the  end  result  operation  is  used  by  the  student  or 
agent  in  first  person. 

The  view  object  command  will  only  show  a  listing  of  operations  by  name  for  an  object.  To  view 
the  entire  definition  of  the  object,  to  include  inheritance  source,  use  the  view  operation  command. 

6.  Pedantic  Summary  Facts. 

Summary  facts  are  useful  for  complex  objects  in  which  you  desire  to  help  streamline  the  output. 
A  summary  fact  is  a  single-phrase  description  of  a  collection  of  properties  about  one  or  more  objects.  It  is 
primarily  an  interface  tool  which  is  used  to  "summarize"  the  state  for  the  user. 

Summary  facts  currently  can  only  be  defined  for  objects,  however,  they  will  soon  also  be 
definable  for  tasks  and  lessons.  They  consist  of  the  following  data  and  are  accessible  via  the  create 
summary  fact,  remove  summary  fact,  and  modify  summary  fact  commands: 

-  The  object 

-  The  name  of  the  summary,  which  is  constructed  similar  to  a  property  set  member:  objeci  $ 
<  summary  descriptor 

-  The  definition  of  the  summary,  which  is  a  list  of  non-contradicting  properties  about  the  object. 

An  example  of  a  summary  fact  for  flashlight  is  "flashlight  is  working",  defined  as  "flashlight^ 
chassis  is  assembled",  "flashlights  top  is  assembled",  "flashlights  batteries  are  working”,  "flashlights 
bulb  is  working”.  So  with  this  summary  fact  should  all  four  defining  members  be  true,  then  the  four  are 
not  printed  out  to  the  student  Instead,  just  the  summary  "flashlight  is  working"  is  printed. 

Summary  facts  are  currently  not  available  when  using  tasks  -  either  as  defined  among  a  set  of 
objects  or  as  a  shortcut  in  building  task  definitions.  This  is  an  item  for  future  implementation.  The  only 
time  summary  facts  are  used  is  in  the  METutor  lesson  itself. 
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The  view  object  command  will  only  list  the  object's  summary  facts  by  name.  To  get  the  complete 
definition  of  a  summary  fact,  use  the  view  summary  fact  command.  The  command  will  also  show  the 
inheritance  source  of  the  summary  (whether  defined  or  inherited  from  parent  or  component). 

7.  Declaring  Background  Changes. 

Background  changes  model  changes  of  state  not  caused  by  an  external  stimulus.  That  is  to  say 
that  die  object  or  objects  change  state  on  their  own,  due  to  the  object  being  in  some  given  condition 
(though  not  necessarily).  An  example  of  this  is  that  whenever  a  streetlight  is  on,  then  if  the  streetlight  is 
green  then  10  turns 

later  it  will  turn  yellow  and  10  turns  after  that  it  will  turn  red. 

There  are  several  general  models  of  background  changes: 

-  Progression.  The  object  changes  from  state  to  state  within  a  property  set  until  the  last  is  reached 
(which  would  normally  imply  some  other  event  is  to  take  place).  An  example  of  this  is  a  ship  with  a  hole 
in  the  hull  that  progresses  through  "no  water",  "some  water",  "lots  of  water",  "full"  at  which  point  the  ship 
sinks.  Currently  progression  is  forward  only. 

--  Loop.  The  object  goes  back  to  the  beginning.  The  streetlight  loops  through  "red",  "green", 
"yellow".  The  loop  can  only  go  in  one  direction,  it  cannot  be  reversed  at  present. 

-Update.  The  object  performs  an  operation.  (Not  yet  implemented). 

Background  changes  can  be  very  complex,  and  there  are  many  different  options  which  are 
available  for  building  them.  They  consist  of  the  following  pieces  of  data,  and  are  manipulated  using  the 
create  background  change,  remove  background  change .  and  modify  background  change  commands. 

-  A  triggering  condition  list.  The  object  would  be  subject  to  background  changes  while  all  of  the 
conditions  in  the  triggering  condition  list  are  true.  If  the  list  is  empty,  then  the  object  will  always  be 
subject  to  the  change. 

-  The  property  set  corresponding  to  the  state  changes. 

-•  Advancement  method.  How  often  or  what  probability  will  the  next  change  occur. 

The  view  object  command  will  only  display  the  name  of  the  background  changes  in  a  listing.  To 
get  a  complete  definition  of  a  background  change,  use  the  view  background  change  command,  which  will 
also  print  the  inheriteance  source  of  the  background  change  (derived  or  inherited  by  ancestor  or 
component). 

8-  Library  Management  with  Qhjflcis- 

You  may  save  your  object  at  any  time  using  the  save  object  command.  The  load  object  command 
will  load  the  object  into  the  session,  along  with  the  entire  parent  and  component  class  hierarchies.  This 
last  note  is  important  since  you  may  note  that  several  objects  are  loaded  in  that  you  did  not  request  loaded. 
This  feature  ensures  that  all  inherited  object  definition  data  is  available  at  all  times  while  the  object  is 
being  accessed. 

You  may  also  delete  and  restore  objects  from  the  library.  The  remove  object  command  will  mark 
an  object  for  deletion,  while  the  restore  object  unmarks  it.  Upon  exit  from  MEBuilder,  all  objects 
removed  from  the  library  will  be  permanently  purged.  Important:  Once  an  object  has  been  purged,  all 
other  objects,  tasks,  and  lessons  that  use  the  object  are  invalid  and  must  be  reconstructed.  Be  sure  you 
know  wiutt  you  are  doing. 
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(NOTE:  These  two  commands  are  not  yet  implemented.) 

Finally,  to  see  if  the  object  has  a  valid  definition  (that  the  modification  or  removal  of  data  did  not 
leave  pny  undefined  remnants,  use  the  chtck  objtct  command. 


TAB  5.  STEP  TWO  -  DESIGNING  A  TASK 


1.  What  is  a  Task? 

A  task  is  the  fundamental  building  block  of  a  lesson.  It  describes  a  single  behaviour  of  a 
character  (called  an  "actor")  with  respect  to  a  defined  starting  point  and  a  defined  goal.  This  behaviour  is 
described  in  terms  of  a  "sequence"  of  primitive  operations. 

The  task  does  several  things.  First,  it  establishes  relationships  among  the  primitive  operations 
which  the  operations  themselves  do  not  cover.  Second,  it  allows  the  teacher  to  identify  and  build  alternate 
solutions  to  the  problem  to  be  eventually  given  to  the  student  Finally,  it  cross-checks  the  teacher's  intent 
with  the  object 

definitions  to  guaranteed  correctness  and  consistency. 

The  task  is  made  up  of  the  following: 

-  An  actor.  This  is  the  one  individual  with  primary  responsibility  for  performing  the  task.  The 
actor  must  be  a  character  class. 

«  A  list  of  other  objects  required  for  the  task.  Some  tasks  may  involve  multiples  of  the  same 
object  DO  NOT  treat  components  of  an  object  as  a  separate  object! 

-  The  initial  conditions  that  each  object  is  in  at  the  beginning  and  the  objectives  that  define  when 
the  task  is  complete. 

Important  point  about  tasks.  Tasks  are  built  in  terms  of  a  known  start  and  a  known  finish. 
However,  the  task  is  designed  so  that  the  student  can  react  to  a  state  which  is  in  the  middle  of  the  task  or  a 
state  which  is  outside  the  bounds  of  the  task.  In  each  case,  the  task  provides  the  underlying  rules  describing 
which  operations  can  be  applied  and  which  cannot.  Therefore,  there  is  no  restriction  at  the  lesson  level 
which  prevents  a  lesson  scenario  from  presented  a  situation  that  does  not  directly  conform  to  the  initial 
conditions  of  any  task. 

2.  ProamiK  of  Tusks  --  Sicas  and  Step  Dcpcndmay- 

Tasks  are  described  as  a  sequence  of  steps  and  each  step  consists  of  a  task  operation .  The 
difference  between  a  task  operation  and  a  primitive  operation  is  that  the  task  operation  gains  additional 
preconditions  based  on  the  sequence  of  steps  in  the  task.  So  task  operations  are  task-specific,  whereas 
primitive  operations  are  more  general.  Steps  are  identified  by  number,  listed  in  front  of  the  operation  :n 
brackets  -  such  as  [3].  For  commands  that  use  <step>  as  an  argument,  it  is  the  number  in  brackets  that  is 
required  (this  requires  less  typing  than  the  entire  operation  name). 

Tasks  are  not  strictly  linear,  however.  Some  tasks  can  be  performed  in  several  different 
sequences  of  operations,  usually  because  there  are  operations  in  the  task  that  are  completely  unrelated.  In 
this  case,  a  single  step  may  contain  several  "subprocedures": 

[2]  open  th*  widget 

[3]  ell  of  the  following. 

[3e]  subprocedure . 

13el]yenk  the  widget '■  red  wire 
[3e2]yenk  the  widget' e  yellow  wire 
( 3b]  subprecedure  t 

(3bl]seel  the  room 
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(3b2] deploy  the  bonh  egued 

(4]  yuk  the  widget '  e  blue  wire 

This  implies  that  step  [2]  comes  first,  and  that  [3al]  must  precede  [3a2],  But  it  does  not  imply 
any  special  ordering  between  [3al]  or  [3bl]  other  than  both  must  be  done  before  [4],  So  the  following  are 
valid  solutions  •*  2-3al-3bl-3a2-3b2-4, 2*3bl-3al-3a2*3b2-4,  etc. 

There  is  an  important  principle  that  governs  when  steps  can  be  moved  around  the  procedure  and 
where,  and  this  is  called  step  dependency.  A  task  operation  X  is  dependent  on  another  task  operation  Y  if 
and  only  if  the  intended  effect  or  any  side  effect  of  the  primitive  operation  Y  is  a  precondition  of  the 
primitive  operation  X.  What  this  means  is  that  no  matter  how  the  teacher  decides  tc  describe  the  task,  X 
cannot  precede  Y.  Therefore,  there  will  be  limits  to  the  options  given  to  the  teacher  when  moving  task 
operations  about  the  task.  To  see  which  operations  are  dependent  on  others,  you  may  do  the  view  step 
dependencies  command. 

During  construction  of  the  task,  the  ordering  of  steps  adds  more  dependencies.  Step  [X+l]  is 
always  dependent  on  step  [X],  and  similarly  substep  [XQg]  is  dependent  on  [XQf]  for  some  subprocedure 
Q  in  step  X.  If  step  [X]  is  a  divided  step  (meaning  that  is  contains  subprocedures),  then  step  [X+l]  is 
dependent  on  *all*  of  the  last  steps  in  each  subprocedure  of  [X]. 

When  you  manipulate  the  task  to  change  the  ordering  of  steps  etc.,  the  options  given  are  based  on 
the  primitive  operation  dependencies.  Step  dependency  car  be  changed,  the  primitive  operation 
dependencies  cannot.  In  order  to  modify  the  latter,  you  must  modify  the  object  definitions  appropriately. 

3.  Sinning  a  New  Task -  Naming  Qhistts.  and  Selling  ihc  Intiiial  Conditions  Mflfihiaaitta- 

To  create  a  new  task,  use  the  create  task  command.  This  command  will  take  you  through  a  series 
of  steps  which  will  initialize  the  task  into  hopefully  a  solvable  form. 

a.  Naming  the  Objects  Involved.  You  will  be  asked  for  the  actor  in  the  task.  The  actor  must  be  a 
character  object  (the  generic  character  object  is  sufficient,  and  will  probably  be  the  one  most  commonly 
used).  Then  you  will  supply  the  object  types  for  all  the  remaining  objects.  You  are  allowed  to  repeat 
objects.  If  you  repeat  objects,  the  second  object  of  the  same  type  will  be  objectl.  The  third  will  be  object2. 

b.  Setting  the  Initial  Conditions.  Initial  conditions  describe  the  initial  states  of  the  objects  within 
a  given  task.  These  initial  states  are  established  in  order  to  ensure  that  every  property  set  associated  with 
an  object  has  a  value  assigned.  After  the  task  is  defined,  you  may  use  the  set  initial  conditions  command 
to  change  them,  and  the  view  initial  conditions  command  to  view  them.  Notes  about  initial  conditions: 

(i)  You  can  only  choose  one  member  of  the  property  set  to  be  in  the  initial  condition^. 
You  should  choose  the  property  set  that  satisfies  the  most  general  case  of  the  task.  It  should  not  be 
necessary  to  create  separate  tasks  based  on  an  initial  condition  set  with  a  variable  member. 

(ii)  If  a  property  set  is  declared  hideable,  then  its  value  being  known  and/or  unknown  is 
considered  a  separate  property  set  and  must  be  set 

c.  Setting  the  Objectives.  Objectives  define  for  some  prop  or  character  the  point  the  goal  of  the 
task  or  lesson. After  the  task  is  initialized,  the  set  objectives  and  view  objectives  commands  are  available. 
There  are  some  subtle  differences  in  the  context  of  which  prop  or  character 
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(i)  In  the  case  of  the  prop,  the  objectives  define  what  state  the  prop  is  in  when  the  task  or 
lesson  is  completed. 

(ii)  In  the  case  of  the  character  which  is  not  the  student's  role,  the  objectives  define  the 
state  that  the  character  is  always  trying  to  achieve.  It  is  best  described  as  the  state  where  he  has  no  work  to 
do. 


(iii)  In  the  case  of  the  character  which  *is*  the  student's  role,  the  objectives  define  the 
state  which  signals  die  end  of  the  lesson  (or  task). 

Like  the  initial  conditions,  objectives  are  defined  for  each  object  in  the  task  vT  lesson.  The  state 

for  each 

object  should  only  list  those  properties  absolutely  necessary,  you  must  explicitly  identify  those  properties 
that  are  "don't-cares"  -  MEBuilder  uses  the  term  "^property  set>  is  immaterial."  In  order  to  prevent  the 
unnecessary  or  unplanned  exclusion  of  some  solutions  to  the  problem,  make  maximum  (but  well-planned) 
use  of  the  "dont-care"  cose. 

d.  MEBuilder  Determines  the  Initial  Solution.  MEBuilder  will  try  to  find  *»*  solution  to  the 
problem.  Once  it  does,  it  will  construct  an  initial  procedure  based  on  the  premise  that  the  solution  it  found 
it  die  only  solution.  The  steps  will  be  numbered  [1]  to  [n].  The  solution  is  based  solely  on  the  primitive 
operations,  and  it  may  not  even  be  correct  according  to  what  you  intended!  You  should  accept  the  solution 
(forcing  it  to  find  a  second  solution  could  take  quite  a  long  time)  and  use  the  commands  in  the  next  section 
to  manipulate  it  to  the  procedure  you  really  want 

4.  Modifying  the  Task  -  Allowing  for  Multinle  Solution. 

There  are  several  ways  thru  you  can  manipulate  the  task  once  the  first  solution  is  established.  It  is 
important  to  note  that  all  of  these  commands  are  restricted  under  tlte  rules  of  dependency  described  earlier 
in  this  section. 

a.  Declaring  Subprocedures.  The  find  splits  command  will  locate  sets  of  operations  that  appear 
unrelated  and  could  be  made  into  subprocedures.  The  inverse  of  this  is  the  combine  step  command.  The 
combine  step  command  does  the  inverse  -  it  takes  two  subprocedures  (actually,  the  first  step  of  each  of 
two  subprocedures)  and  combines  them  together  into  one  sequence  of  actions. 

b.  Swapping  Steps.  Two  adjacent  steps  may  be  in  the  incorrect  order.  As  long  as  step 
dependency  permits,  you  may  use  the  swap  step  command  to  reverse  them. 

c.  Moving  A  Single  Step  Around  the  Task.  Sometimes  the  find  splits  command  correctly 
identifies  subprocedures  except  that  rate  or  two  of  the  operations  should  be  included  or  excluded.  The 
move  step  command  remedies  these  problems.  In  addition,  this  command  allows  naming  the  step  as  a 
single-action  subprocedure,  and  you  can  create  a  set  of  permutable  actions  with  this  single-action 
subprocedure.  For  example  if  [4]  and  [S]  are  independent,  then  doing  a  move  step  number  S  will  allow 
you  to  merge  [4]  and  [S]  into  [4al]  and  [4bl].  This  can  be  extended  to  add  the  one-action  subprocedure  to 
an  already  existing  set  of  permutable  actions. 

d.  Declare  Unordered  Actions.  The  move  step  is  also  used  for  this  purpose.  Steps  may  be 
declared  unordered  (and  they  will  appear  with  an  asterisk  to  the  terminal).  This  same  command  can  also 
be  used  to  reorder  die  operation.  Unordered  actions  are  those  which  do  not  follow  the  strict  ordering  of  the 
task  except  that  they  must  precede  the  next  step.  For  example,  if  step  [6]  is  unordered  it  may  be  done  at 


I 


112 


any  lime  (assuming  its  preconditions  are  met),  but  it  must  be  done  before  step  [7].  They  greatly  add  to  the 
flexibility  of  the  lesson. 

5.  Vlewlnn  and  Special  Commands. 

The  reset  task  command  is  useful  if  you  decide  you  wish  to  start  over.  MEBuilder  will  restore 
the  initial  single  solution,  clearing  all  subprocedure  information. 

The  view  task  prints  out  the  task  in  its  present  form.  This  is  useful  if  you  wish  to  get  the  current 
step  arrangement. 

The  view  situation  command  prints  out  the  state  that  is  true  after  a  given  operation  has  been 
performed.  This  is  useful  for  uncovering  reasons  why  a  particular  solution  was  declared  valid  when  you 
feel  it  should  not  have  been. 

The  modify  stop  command  allows  you  to  add  additional  preconditions,  side  effects,  and  messages 
to  the  task.  Once  these  are  specified,  the  task  is  recalculated  based  on  the  changes.  This  is  an  especially 
important  command  if  you  wish  to  introduce  probabilities  into  the  problem  (such  as  there  is  a  15%  chance 
of  a  fire  rekindling  after  you  have  extinguished  it). 


6.  Lihrarv  Management  of  Tasks. 


The  load  task .  save  task ,  remove  task,  restore  task .  and  check  task  commands  are  analogous  to 
their  object  counterparts.  The  load  task  command  will  merely  load  the  task  into  the  session,  it  will  not 
automatically  invoke  the  Task  Loop,  check  task  will  fust  perform  a  check  object  on  all  objects  in  the  task. 

In  addition,  in  order  to  edit  a  task,  you  may  use  the  work  oh  task  command  to  enter  ttie  Task 
Loop.  This  command  will  ensure  the  task  is  loaded  first,  and  load  it  if  necessary. 
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TAB  6.  STEP  THREE -DESIGNING  THE  LESSON 


1.  What  is  a  Lesson? 

An  MEBuilder  lesson  is  effectively  a  workbook  filled  with  individual  problems,  similar  to  an 
exercise  section  at  the  back  of  a  chapter  in  a  textbook.  The  problems  should  be  designed  to  meet  any  or  all 
of  the  following  needs: 

-  Cover  different  pieces  of  a  topic,  perhaps  culminating  with  a  problem  that  covers  the  whole 

thing. 

-  Starting  at  an  easy  level  and  progressing  to  harder  levels. 

—  Demonstrating  knowledge  of  lesson  material  in  multiple  scenarios  (such  as  with  different 
equipment  or  with  different  personnel  available). 

The  workbook  framework  contains  the  main  information  necessary  for  MEBuilder  to  build  an 
METutor  lesson.  These  are: 

-•  A  comprehensive  cast  of  character  roles  and  props  with  the  associated  tanks  to  be  used. 

-  An  introduction  text  for  the  lesson  itself. 

--  A  listing  of  problems.  i 

2.  What  is  a  Problem? 

A  problem  is  a  specific  exercise.  The  student  will  do  the  problems  when  he  runs  the  lesson.  A 
problem  contains  a  scene  which  is  the  scene  presented  to  the  student,  and  contains  a  goal  which  is  what  the 
student  must  achieve.  A  problem  is  constructed  very  similarly  ‘o  a  task  in  that  a  concrete  cast  and  list  of 
props  is  given.  The  problem  also  contains  information  about  the  role  the  student  will  play  (if  there  is  more 
than  one  character  in  the  problem).  Most  lessons  will  have  the  student  play  the  same  role  in  all  problems, 
however  some  might  desire  the  student  to  play  different  roles. 

3.  Building,  a  flew  Lesson- 

lmpor:anv.  Before  constructing  a  new  lesson,  you  must  have  loaded  into  MEBuilder  all  of  the 
objects  and  tasks  you  intend  to  include. 

In  order  to  make  a  new  lesson,  you  may  use  the  ertate  lesson  command  from  Main  Loop  prompt 
to  make  a  new  lesson.  The  command  will  take  you  through  the  process  of  identifying  proper  names  for  the 
cast  and  props  along  with  identifying  their  types.  This  is  the  cast  and  props  that  will  be  present  in  all 
exercises. 

MEBuilder  will  then  identify  the  loaded  tasks  that  coirespond  to  the  given  set  of  objects.  You 
may  choose  all  of  them  or  omit  those  not  needed  for  the  lesson.  However,  every  object  you  specified  must 
be  includable  in  a  task.  In  other  words,  if  you  specified  an  extinguisher  object  but  omit  the  only  loaded 
task  that  uses  an  extinguisher,  then  you  must  reconsider  the  assignment  of  objects  and  tasks.  Ordering  of 
tasks  is  imrmrtantl  The  order  you  specify  determines  the  defaults  for  the  scene  and  the  goal  in  cases  when 
an  object  is  to  be  employed  in  one  or  more  task.  The  default  scene  for  any  object  is  the  initial  conditions 
of  the  first  task  that  uses  it.  The  default  goal  for  any  object  is  the  objectives  of  the  last  task  that  uses  it. 
These  defaults  will  be  relayed  to  you  each  time  you  declare  a  new  problem. 
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Once  the  lineup  is  satisfactory,  you  will  be  in  the  Lesson  Loop,  the  first  thing  you  should  do  in 
create  an  introduction  text  for  the  lesson.  This  should  be  a  general  text  which  describes  the  overall  goals 
of  the  lesson.  Each  problem  will  'nave  its  own  introductory  text.  The  edit  lesson  intro  and  view  lesson 
intro  commands  are  available.  NOTE:  The  edU  lesson  intro  command  uses  emacs  -  and  at  present  this 
cannot  be  set. 

4.  Defining  a  New  Problem. 

Problems  are  defined  by  the  create  problem  command.  This  command  will  initiate  a  sequence  of 
steps  where  you  will  specify  the  student's  role  and  any  cast  members  or  props  who  are  not  to  be  included 
in  this  particular  problem.  Each  problem  is  assigned  a  problem  number ,  which  is  one  more  than  the 
number  of  problems  in  the  lesson.  You  also  provide  MEBuilder  with  a  unique  problem  name,  which  is 
primarily  used  to  help  you  identify  die  problem.  In  most  commands  in  the  Lesson  Loop,  you  may  identify 
a  problem  either  by  its  number  or  its  name. 

The  scene  and  the  goal  will  default  to  the  initial  conditions  and  objectives  of  the  tasks  you 
specified  according  to  the  rules  described  above.  MEBuilder  will  {Hint  out  a  list  of  those  items  as  they  are 
entered.  Once  the  process  is  complete,  you  will  be  in  the  Problem  Loop.  Entering  quit  will  pop  you  into 
the  Lesson  Loop. 

After  a  problem  has  been  created,  you  may  modify  the  problem  definition  with  the  set  scene  and 
set  goal  commands.  The  view  scene  and  view  goal  commands  are  analogous.  The  difference  with  the 
scene  vice  the  initial  conditions  of  a  task,  however,  is  that  you  may  identify  probabilities.  This  means  that 
some  state  member  in  the  scene  is  uncertain.  You  will  be  asked  to  identify  those  probabilities  for  each 
state  member  --  and  those  will  become  a  random  event  in  the  compiled  lesson. 

You  may  edit  and  view  the  introductory  text  for  the  problem  using  the  edit  problem  intro  and 
view  problem  intro  commands.  These  are  exactly  analogous  to  their  lesson  intro  counterparts.  As  with  the 
edit  lesson  intro  command,  emacs  is  the  only  editor  accessible  through  MEBuilder. 

In  order  to  return  to  a  problem  from  the  Lesson  Loop,  you  may  work  on  problem,  specifying  the 
problem’s  name  or  number. 

5.  SeniagiToblem.  Options  (NOT  YEIJMPLEMENTED). 

Options  is  a  method  of  taking  some  of  the  parameters  of  a  problem  and  adjusting  them 
(overriding  the  original  definition  bom  the  task)  in  order  to  change  the  difficulty  of  the  problem. 

None  of  the  following  have  been  fully  implemented  yet,  however,  these  are  the  options  planned: 

-*  Side  effect  blocking.  All  probabilistic  side  effects  as  defined  in  the  task  definitions  are 
nullified.  The  intent  is  to  provide  a  very  simple  problem  with  no  surprises  for  the  student  (good  for  earlier 
problems). 

--  Probability  overrides.  Overrides  the  percentage  of  some  given  side  effect  in  a  task  definition. 
Intent  is  to  perhaps  increase  the  likelihood  of  something  going  wrong. 

--  Background  effect  overrides.  Overrides  the  percentages  or  count  values  in  the  background 
changes  listed  for  some  of  the  objects. 
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-  Character  speed.  Characters  other  than  the  student  can  takes  action  quicker.  For  example,  a 
setting  of  2  for  the  adversary  of  the  student  means  that  the  adversary  gets  two  moves  per  student’s  one 
move. 

As  they  are  implemented,  entries  for  the  associated  commands  will  be  added  to  the  help  system. 
Currently,  the  planned  command  is  simply  set  options. 

6.  Reordering  and  Deleting  the  Problems  in  the  Lesson. 

You  are  allowed  to  renumber  the  problems  using  the  order  problems  command.  This  is  provided 
since  create  problem  only  adds  problems  to  the  end. 

In  addition,  problems  may  be  deleted  using  the  remove  problem  command. 

7.  Accessing  METutor  ~  Compiling  and  Running  Lessons  from  MEBuilder. 

MEBuilder  is  a  lesson  authoring  system  that  was  built  on  top  of  METutor  version  29,  an 
Intelligent  Tutoring  System  (ITS)  shell.  MEBuilder  makes  use  of  several  METutor  facilities  while  helping 
you  build  lessons. 

Creating  an  METutor  lesson  from  MEBuilder  data  is  dene  through  a  "compilation"  process, 
accessible  via  the  compile  lesson  command.  This  command  will  performs  checks  on  all  the  objects,  tasks, 
and  problems  in  the  lesson  and  then  translate  the  entire  database  into  METutor  form.  The  compiled  lesson 
can  be  saved  as  an  METutor  runnable  file  using  the  save  compiled  lesson  command. 

You  can  invoke  an  METutor  session  on  a  lesson  you  have  compiled  by  using  the  run  lesson 
command  in  the  Lesson  Loop.  You  do  not  have  to  explicitly  call  compile  lesson ,  the  run  lesson  command 
will  do  it  automatically.  Quitting  from  METutor  will  return  you  to  the  Lesson  Loop. 

8.  Library  Management  of  Lessons- 

The  load  lesson,  save  lesson,  remove  lesson,  restore  lesson,  and  check  lesson  commands  are 
available  and  mirror  their  object  and  task  counterparts.  In  addition,  the  work  on  lesson  command  enters 
the  Lesson  Loop  on  a  particular  lesson.  As  with  the  task  version,  work  on  lesson  will  load  the  lesson  first 
if  it  hasn’t  already  been  loaded  into  the  session. 
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APPENDIX  C.  SAMPLE  SCRIPT  RUN  WITH  MEBUILDER 


The  following  script  run  with  inserted  comments  is  the  same  sample  script  run  given 
to  the  students  in  the  experiment  described  in  Chapter  VI.  The  problem  requires  a  pilot  to 
execute  the  steps  necessary  to  prepare  a  plane  for  takeoff.  It  is  of  similar  complexity  and 
size  as  those  lessons  used  in  the  experiment  The  script  is  divided  as  follows: 


Tab  1 .  The  Requirements  and  Design  Phase 

Tab  2.  Building  the  Objects 

Tab  3.  Building  the  Task 

Tab  4.  Building  the  Lesson 
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TAB  1.  THE  REQUIREMENTS  AND  DESIGN  PHASE 


This  appendix  will  present  a  sample  session  using  MEBuilder  to  build  a  lesson  from  the  ground 
up.  That  is,  a  requirement  will  be  presented  and  discussed.  We  will  then  go  through  the  process  of 
identifying  the  objects  and  members  of  the  objects,  constructing  associated  tasks,  and  finally  building  a 
lesson  workbook.  We  will  then  demonstrate  the  lesson  compilation  process  and  the  METutor  interface. 

1.  The  Lesson.  Pilot  Training 

The  student  is  a  pilot  who  is  learning  how  to  fly.  His  fust  lesson  is  in  the  process  of  prepping  the 
aircraft  for  takeoff  and  for  the  basic  communications  with  the  air  traffic  control  tower.  At  the  start  of  the 
problem,  all  of  the  devices  in  the  aircraft  are  turned  off  and  the  aircraft  has  not  been  preflight  inspected. 

This  is  a  very  simplistic  description  of  the  procedure  and  the  objects  involved  in  order  to  keep  the 
scope  of  the  problem  reasonable  for  this  appendix.  There  is  a  buffer  present  at  the  terminal  to  help  start 
the  engine.  The  aircraft  has  several  subdevices  associated  with  it.  The  aircraft  has  brakes,  throttles,  an 
engine,  trim,  nose  wheel  steering  ("NWS").  external  power  hookups,  and  an  auxiliary  power  unit  (NAPU  } 
with  its  associated  bleed  air  and  generator.  The  brakes,  trim,  and  NWS  are  unchecked.  The  aircraft  has 
not  been  preflight  inspected.  External  power  is  available  hut  is  off.  The  engine  and  APU  (along  with  its 
associated  components)  are  all  off.  The  pilot  has  not  had  his  flight  plan  cleared  with  tower,  nor  is  he 
cleared  for  taxi  nor  takeoff.  There  is  a  wind  sock  at  the  end  of  the  runway  to  inform  the  pilot  of  the  wind 
speed  and  direction  at  takeoff.  At  the  end  of  the  task,  the  student  should  be  airborne. 

The  sequence  of  steps  is  as  follows; 

(a)  The  pilot  must  do  the  following  in  order  inspect  the  aircraft,  engage  the  external 
power,  engage  the  buffer,  start  the  engines,  start  the  APU,  and  then  engage  the  APU’s  generator  and  bleed 
air.  The  plane  is  own  operating  on  its  own. 

(b)  The  pilot  requests  flight  clearance  while  he  is  checking  the  NWS  and  brakes. 

(c)  He  then  disengages  the  huffer  and  the  external  power,  requests  taxi  clearance  and 
taxis  to  the  runway. 

(d)  At  the  edge  of  the  runway,  he  requests  takeoff  clearance  while  he  is  checking  the 
wind  sock  and  adjusting  the  trim  on  his  aircraft. 

(e)  Once  his  takeoff  clearance  is  granted,  he  pushes  the  throttles  to  max  and  flies  the 

airplane! 

2.  Design  the  Objects  and  the  Map  the  Scenario 

For  the  purposes  of  this  sample,  we  will  only  concern  ourselves  with  the  fundamental  building 
blocks  of  objects  -  components,  property  sets,  and  operations.  We  will  not  include  summary  facts  and 
background  changes  nor  will  we  employ  an  object  hierarchy  other  than  identifying  props  and  characters. 
There  are  two  steps  to  this  process  ••  first  identifying  the  makeup  of  the  objects,  then  defining  the  behavior. 

a.  A  'up  the  Scenario 

Generally  speaking,  most  applications  will  not  come  in  a  nice  tidy  procedural  listing 
such  as  that  given  above.  The  best  thing  to  do  for  any  application  is  start  by  identifying  the  specific 
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sequences  of  events  that  must  occur  and  list  then  in  order  step  (a)  through  (z).  Grouping  set  sequences 
together  such  as  (a)  above  is  ideal.  Devote  a  step  to  sequences  of  events  where  order  is  unimportant,  such 
as  (d)  --  but  be  sure  to  identify  what  ordering  is  allowed  and  what  is  not.  For  example,  in  (d)  checking  the 
wind  sock  must  come  before  adjusting  the  aircraft's  trim.  So  the  following  are  legal:  clearance- wind  sock- 
trim,  wind  sock-clearance-trim .  and  wind  sock-trim-clearance. 

b.  Identify  and  Design  the  Objects  and  Component  Relationships 

There  are  several  objects  listed  in  the  above  scenario.  However,  as  we  identify  these 
objects  we  must  also  identify  those  objects  which  are  components  of  other  objects  or  are  possessions  of 
characters.  The  following  is  the  breakdown  of  objects  in  this  task: 

(1)  the  aircraft  --  a  prop,  with  the  following  components: 

(a)  auxiliary  power  unit  -  with  the  following  components: 

(i)  generator 

(ii)  bleed  air 

(b)  brakes 

(c)  engine 

(d)  external  power  hookup 

(e)  nose  wheel  steering 

(f)  throttles 

(g)  trim 

(2)  the  pilot -a  character 

(3)  thehuffer-aprop 

(4)  the  wind  sock -- a  prop 

(We  are  not  going  to  model  the  air  traffic  control  tower  as  a  separate  object  for  this 

example.) 


c.  Identify  the  Behaviour  --  the  Properties  and  the  Operations 

The  property  sets  and  the  operations  go  hand-in-hand.  For  each  property  described  in 
the  task,  we  might  want  to  consider  an  operation  that  achieves  it.  The  key  for  successfully  doing  this  is  to 
keep  it  simple.  Do  not  include  attributes  that  are  redundant  or  unnecessary. 

We  will  start  with  the  pilot.  The  pilot  is  the  one  doing  all  the  work,  however  most  of  the 
work  is  in  changing  the  state  of  the  aircraft,  not  the  pilot  Three  are  three  things  die  pilot  does  that  clearly 
changes  his  own  state  -  requesting  the  three  clearances.  We  say  this  because  clearance  to  taxi,  etc.,  is 
requested  by  and  granted  to  die  pilot  not  the  aircraft.  Because  the  pilot  is  a  character,  the  operations  will 
begin  with  the  key  phrase  "have  pilot",  which  will  be  chopped  off  during  the  lesson  so  the  student  will 
view  things  first  hand. 

There  are  several  ways  to  model  the  pilot's  state.  We  could  either  model  the  three 
clearances  as  three  different  property  sets  or  model  all  three  as  a  single  property  set  with  a  fourth  member  - 
•  pilot  is  uncleared.  Generally  speaking  the  former  method  is  preferable  since  the  fact  that  a  pilot  is 
cleared  for  taxi  and  departure  could  be  used  in  several  contexts.  Only  in  cases  where  all  values  a  strictly 
mutually  exclusive  should  they  be  combined. 

When  designing  the  objects,  the  best  way  to  do  it  is  to  set  up  a  table  mapping  properties 
to  operations  and  operations  to  other  data.  Group  possible  property  sets  together  and  label  them.  The 
following  is  a  good  example: 
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Property  Opetation  to  Achieve  it  Precondition 

flight  clearance: 

pilot  ii  cleared  to  depart  have  pilot  request  flight  clearance 

pilot  is  not  cleared  to  depart  <none> 

taxi  clearance: 

pilot  it  cleared  to  taxi  have  pilot  request  taxi  clearance 

pilot  it  not  cleared  to  taxi  <none> 

takeoff  clearance: 

pilot  is  cleared  to  take  off  have  pilot  request  takeoff  clearance 

pilot  is  not  cleared  to  take  off  <none> 

Now,  let's  examine  the  task  description  and  see  what  other  information  we  can  gather. 
For  designing  the  operations,  we  must  identify  the  preconditions.  Using  the  scenario  mapping,  this  is 
easy.  For  example,  in  order  to  request  the  flight  clearance,  the  APU  bleed  air  on  the  aircraft  must  be  on. 
MESuilder  automatically  assumes  that  the  pilot  is  not  cleared  to  depart  so  it  is  not  necessary  to  include  that 
precondition. 


Property 
flight  clearance: 

Operation  to  Achieve  it 

Precondition 

pilot  is  cleared  to  depart 
pilot  is  not  cleared  to  depart 

have  pilot  request  flight  clearance 
<none> 

aircraft's  bleed  air  must  be  on 

taxi  clearance: 

pilot  is  cleared  to  taxi 
pilot  is  not  cleared  to  taxi 

have  pilot  request  taxi  clearance 
<none> 

aircraft's  external  power  is  off 

takeoff  clearance: 

pilot  is  cleared  to  take  off 
pilot  is  not  cleared  to  take  off 

have  pilot  request  takeoff  clearance 
<none> 

air ci  aft  must  be  on  the  runway 

In  similar  fashion,  here  are  some  the  aircraft's  properties  and  operations  (We  will  not  include  all 
of  them  in  the  interest  of  space). 

Property  Operation  to  Achieve  it  Other  Information 

location: 

aircraft  is  at  the  terminal  <none> 

aircraft  is  on  the  runway  taxi  the  aircraft  pilot  must  be  cleared  to  taxi 

aircraft  is  airborne  fly  the  aircraft  aircraft's  throttles  must  be  maxed 

NWS  check  status: 

aircraft's  NWS  is  checked  check  the  aircraft's  NWS  aircraft's  bleed  air  must  be  on 

aircraft's  NWS  is  not  checked  <none> 

Once  you  have  built  these  tables  for  all  the  objects,  you  are  ready  to  start  the  MEBuilder  session. 
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TAB  2.  BUILD  THE  OBJECTS 


The  best  way  to  approach  constructing  the  objects  is  to  do  the  following  in  order 

••  Create  all  the  objects 

-  Connect  all  the  components 

-  Define  all  the  property  sets 
-•  Define  all  the  operations 

We  will  now  begin  an  MEBuilder  session.  Notice  that  MEBuilder  automatically  creates  a  library 
directory  for  us  (assuming  this  is  our  first  session): 

script  started  on  Tua  Jul  26  10 t 33 t 14  1994 
.•Hast  Ho  such  file  or  directory. 

>  -gelvint /nebulld/MXBuilder 

+ - .... - ... - - - - ........ — ... - + 

I  NMM-l&di  Virtual  World  and  Lesson  Builder  —  KEBuildar  I 
I  Cfl  Thomas  9.  Oalvin,  us  A rmy,  Haval  Postgraduate  School  I 


Type  "help"  for  assistance  I 


MBBuildar  local  library  not  found. .creating. . . 

UtBullder  local  library  loaded. 

/OBUILZ» 

a.  Creating  the  Objects.  Now  we  will  use  the  create  object  command  to  create  all  the  objects 
(this  includes  all  of  the  objects  that  will  become  components  of  aircraft).  The  following  is  a  portion  of  the 
script. 

MBBUIU»  create  object  named  pilot 

The  following  are  the  available  parent  claaaaa. 

(1]  prop 

[3]  character 

ch  i  one  of  the  rbove>  3 

“pilot"  ia  now  defined. 

M?  1»  create  object  named  buffer 

The  X lowing  are  the  available  parant  claaaaa. 

iD  prop 

[3]  character 

[3]  pilot 

Chooae  <  ,e  of  the  above >  1 
claaa  l:  .  fter"  ia  now  defined. 

KBBUXLD>  create  object  named  wind  sock 

The  l  wing  are  the  available  parant  claaaaa . 

tl)  prop 

12)  character 

13)  pilot 

14)  buffer 

Choose  one  of  the  abova>  1 
Class  "wind  sock"  ia  now  defined. 

MBBUXLD>  create  objeat  named  aircraft 

The  following  era  the  available  parant  olaaaas. 

tl)  prep 

t2]  character 

t3]  pilot 

14]  buffer 

15]  wind  lock 
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Choose  on*  o t  tkt  abon>  1 
Class  “aircraft "  Is  bow  defined, 

NKBUXLD>  oraata  object  UMi  aircraft  UD 
The  follow  iso  ara  tbs  available  par  act  elassas. 
til  prep 

(2]  character 

11]  pilot 
t4)  buffer 

f S3  vlad  sock 

[<]  alreraft 

Choose  «a  of  the  above  >  1 

Class  "aircraft  APU"  Is  sow  defined. 

MUOXXiD* 

Note  that  all  of  the  created  objects  become  options  for  parent  objects.  In  the  same  manner,  the 
aircraft  APU  generator,  aircraft  APU  bleed  air,  aircraft  brakes,  aircraft  engine,  aircraft  external  power, 
aircraft  NWS,  aircraft  throttles,  and  aircraft  trim  objects  are  all  created.  Other  commands  useful  here 
include  view  object  and  change  parent  object. 

b.  Defining  Components.  We  will  demonstrate  the  process  of  combining  a  component  object 
together.  This  is  with  the  create  component  command.  We  will  only  show  the  construction  of  the  aircraft 
APU  with  its  generator  and  bleed  air.  As  specified  in  the  command  reference,  you  do  not  have  to  provide 
the  "named"  and  the  "for”  arguments  on  the  command  line  -  ME  Builder  will  prompt  those  automatically. 
However.  MEBuilder  will  always  provide  a  menu  for  the  component’s  type. 

MKB0ZU>>  craats  aoopoaant  named  generator  for  alreraft  APU 
Chocs*  the  class  of  th*  as v  component  frost  eas  ofi 
HI  pilot 

12]  huff or 

[3]  wind  sock 

U]  aircraft 

15]  aircraft  JUKI  gaaarator 

[6]  aircraft  APU  blaad  air 

17]  aircraft  brakas 

IS]  alreraft  angina 

I®]  alreraft  sxtoraal  power 

CIO]  alreraft  ms 

HI]  alreraft  throttiaa 

H2]  aircraft  trim 

Cboeso  era  of  th*  above >  5 

I  asauao  “generator”  is  a  singular  nests. Correct?  tYss/No]  yss 
Component  “gansrator"  da fined  for  elass  "aircraft  ATU" , 

MDUZU>>  oraata  coopoaaat  nested  blaad  air  for  aircraft  APU 
Choose  the  class  of  the  n«w  component  frost  oas  oft 
HI  Pilot 

U]  buffer 

HI  wind  sock 

[4]  alreraft 

(5]  alreraft  apu  generator 

t*]  alreraft  APU  blaad  air 

(7)  aircraft  brakes 

(•]  aircraft  angina 

H]  alreraft  ostaraal  power 

HO]  alreraft  ms 

HI]  alreraft  throttlas 
H2]  aircraft  trim 
Choose  oas  of  tbo  above >  5 

X  as  bum  "bleed  air"  is  a  singular  saw.  Correct?  [Yes /No]  yes 
Cespenaat  “bleed  sir"  defined  for  class  "aircraft  APU". 
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mbbuxld> 


In  similar  fashion,  the  seven  components  of  aircraft  are  attached.  Once  this  is  done,  it  would  be 
wise  to  save  all  the  objects.  NOTE:  saving  the  aircraft  automatically  causes  all  component  objects  to  be 
saved  also.  You  can  check  this  using  the  view  library  command.  As  a  check,  here  is  what  the  view  object 
command  will  produce  on  aircraft  when  this  step  is  completed. 

MEBtIXU>>  view  object  named  aircraft 
Class  "aircraft"  is  clean 

Dependencies!  aircraft  trim,  aircraft  throttles,  aircraft  MWS, 

aircraft  external  power,  aircraft  angina,  aircraft 
brakes,  aircraft  APU,  and  prop 
Class  "aircraft*  is  a  prop  class  with  superclass (as)  "prop". 

Class  "aircraft"  has  no  derived  classes. 

Coaponenta  of  elass  "aircraft"! 

[11  "APU"  of  class  "aircraft  APU" 

[2]  "brakes"  of  class  "aircraft  brakes" 

[3]  "engine"  of  class  "aircraft  engine" 

[4]  "external  power”  of  elass  "aircraft  external  power" 

[5]  "NWS"  of  class  "aircraft  DM" 

161  "throttles"  of  class  “aircraft  throttles" 

[7]  "trim"  of  class  "aircraft  trim" 

It]  "APO's  generator"  of  class  "aircraft  APU  generator" 

[9]  "APU 'a  bleed  air"  of  class  "aircraft  APU  blead  air" 

Property  Bets  of  Class  "aircraft" i 
<none> 

summery  Pacta  of  elass  "aircraft" ■ 

<none> 

Property  Display  Data  of  class  "aircraft" t 
<none> 

Operations  of  Class  "aircraft" t 
«aone> 

operation  Display  Text  of  class  "aircraft" < 

<none> 

Background  changes  of  Class  “aircraft"! 

<noae> 

MHUXU» 

Other  useful  commands  relating  to  components  are  remove  component ,  view  component ,  and 
modify  component  Refer  to  the  command  reference. 

c.  Defining  the  Property  Sets.  The  next  step  is  to  put  in  the  first  column  of  our  property- 
operation  table.  The  reason  why  we  must  enter  all  the  properties  first  is  because  we  cannot  define  an 
operation  that  involves  a  pilot  and  an  aircraft  unless  the  properties  of  both  are  defined.  Therefore,  it  is 
good  practice  to  ensure  complete  of  the  property  sets  before  working  on  operations. 

We  will  show  the  process  for  a  one  of  the  pilot's  sets,  then  show  a  couple  for  the 
aircraft.  The  create  property  set  command  is  used  here.  First  the  flight  clearance  for  the  pilot  NOTE: 
Notice  that  the  "not"  member  is  not  given.  Sets  that  have  only  one  listed  member  automatically  have  a  not 
second  member.  Do  not  give  the  "not"  version! 

MU8XU»  create  property  set  nuwd  flight  clearance  for  pilot 
type  "exit"  to  leave . 

Bow  fraptrtyi  pilot  la  —  cleared  to  depart 
Maw  Property!  pilot  is  —  exit 

Doom  this  aet  correspond  to  Information  that  could  be  hidden  from  the 
student?  Ansver  yes  or  mo. 
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>>  BO 

Property  aat  "flight  claaraaea"  dafinad  for  elaea  "pilot". 

moxu>> 

Also  note  >•  this  example  does  not  demonstrate  hidden  property  sets.  This  is  an  advanced  feature 
which  will  be  demonstrated  in  a  separate  example  in  future. 

Now,  a  demonstration  of  aircraft's  location: 

MSBUXU»  create  property  tot  UMt  location  for  aircraft 
typo  "axlt"  to  laava . 

Maw  Property i  aircraft  la  --  at  tha  terainal 
Maw  Property!  aircraft  ia  —  on  tha  runway 
Maw  Property!  aircraft  la  —  airborne 
Maw  Prcpartyt  aircraft  la  —  axlt 

Soaa  thla  aat  eorraapoad  to  information  that  could  ba  hlddan  froa  tha 
atudantt  Aaawar  yaa  or  no . 

>>  BO 

Proparty  aat  "location"  da tin ad  for  claaa  "aircraft". 

nnuxu» 

Now  we  will  demonstrate  the  building  of  the  NWS  check  status.  Note  first  that  the  NWS  check 
status  is  not  a  property  set  of  the  aircraft  but  of  the  component  object!  Properties  describing  components 
are  always  identified  with  their  component  object  type.  "Location"  describes  the  whole  aircraft,  which  is 
why  it  is  a  set  of  the  aircraft. 


NX»OXU»  o rente  proparty  aat  for  aircraft  HNS 
Pleaee  naaa  tha  bow  proparty  aat>  chack  atatua 
Type  "aait"  tc  laava. 

Raw  Proparty i  aircraft  DW  la  —  uaehaekad 
Haw  Property i  aircraft  MRS  la  —  ahaekad 
Haw  Prcportyi  aircraft  HW3  ia  —  aeit 
Haw  Preparty i  aircraft  HNS  ia  -•  axit 

Soaa  thla  aat  correspond  to  information  that  could  ho  hidden  fro®  tha 
student?  Aaawar  yaa  or  nc. 

»  no 

Proparty  aat  "aback  atatua"  defined  for  claaa  "aircraft  HNS". 

Oops!  we  mistyped  "exit”  and  wound  up  with  an  extra  property  set  member.  To  fix  this,  we  will 
demonstrate  the  modify  property  set  loop.  Most  of  the  modify  commands  in  the  object  layer  follow  this 
type  of  a  format.  The  definition  of  the  object's  property  set  is  given  and  you  select  the  specific  attribute  to 
change. 

MBHOXU>>  Modify  proparty  aat  naaad  chack  atatua  of  alraraft  HNS 

Typa  "halp"  for  help.  Type  tha  label  to  change, 

saw*  —  chack  atatua 

dew* la  —  unchecked,  ehaekad,  and  aeit 

hide  —  not_hldaabla 

NODXPT  PHOPHHTT  m>  domain 

Typa  "axlt"  to  loava. 

Haw  Propartyi  aircraft  HHS  la  --  unchackad 

Haw  Prcpartyt  alrcraf.  HNS  la  —  ehaekad 

Haw  Prcpartyt  aircraft  HNS  la  —  axlt 

Typa  "halp"  tor  halp,  Typa  tha  labal  to  change. 

mi  -•  chack  atatua 

dNMin  —  unchackad  and  ehaekad 

hi  da  —  not_hldaahla 
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Mo&xrr  t<Mram  m>  *uit 

lm  okiiign  to  proparty  iitl  y«* 
tzoparty  tot  aodlf loatloa  eeaplatod. 

k nnu> 


In  sunilar  fashion  we  have  defined  the  following  property  sets  for  all  the  objects: 


Pilot: 

Flight  Clearance 

Taxi  Clearance 
Takeoff  Clearance 

Huffen 

Presence 

Engagement 

WindSock: 

Check  Status 

Aircraft: 

Location 

Aircraft: 

Preflight  Completion 

Aircraft  APU: 

Switch  Position 

APU  Bleed  Air: 

Switch  Position 

APU  Generator: 

Switch  Position 

Aircraft  NWS: 

Check  Status 

Aircraft  Brakes: 

Check  Status 

Aircraft  Engine: 

Running  Status 

A.  External  Pwn 

Usage 

A.  External  Pwn 

Switch  Position 

Aircraft  Thrott.: 

Position 

Aircraft  Trim: 

Check  Status 

"cleared  to  depart"  and  "not  cleared  to  depart" 
"cleared  to  taxi"  and  "not  cleared  to  taxi" 

"cleared  to  takeoff  and  "not  cleared  to  takeoff 
"present"  and  "not  present" 

"engaged"  and  "disengaged" 

"checked"  and  "not  checked" 

"at  the  terminal",  "on  the  runway",  and  "airborne" 
"preflight  inspected"  and  "not  preflight  inspected" 
"off  and  "on" 

"off  and  "on" 

"off  and  "on" 

"unchecked"  and  "checked" 

"unchecked"  and  "checked" 

"off  and '  running" 

"available",  "used",  and  "bypassed" 

"off"  and  "on" 

"off,  "idle",  and  "max" 

"unchecked"  and  "checked" 


Other  useful  commands  for  property  sets  are  remove  property  set  and  view  property  set. 

d.  Defining  the  Operations.  Now  we  will  define  the  operations  using  the  same  table  through  the 
use  of  the  create  operation  command.  The  process  is  very  simple,  but  there  are  several  steps  involved. 
Here  is  the  sequence  of  questions  ask  sd: 

-  Name  all  the  objects  involved. 

~  Provide  the  primary  purpos  e,  or  "intended  effect"  of  the  operation.  The  intended  effect  is  the 
property  to  the  left  of  the  operation  name. 

"  Provide  the  preconditions.  These  are  given  in  the  third  column. 

-  Provide  th-  side  effects.  None  of  the  operations  have  side  effects.  Side  effects  are  other 
changes  that  occur  that  aren't  the  primary  purpose  of  the  operation. 

For  the  first  demonstration,  we  will  do  the  one  operation  for  the  wind  sock.  The 
operation  "check  wind  sock"  will  be  used  to  achieve  "wind  sock  is  checked".  Looking  at  the  task,  the 
precondition  for  this  operation  is  that  the  "aircraft  is  on  the  runway". 

One  important  note.  Notice  that  the  pilot  object  is  identified  as  a  necessary  object  even 
though  there  are  no  preconditions  or  side  effects  involving  pilot  In  general,  if  a  specific  character  type 
(not  the  generic  "character")  is  the  one  who  will  perform  a  given  operation,  then  that  character  should 
always  be  included  in  the  other  objects  list.  This  is  to  insure  that  the  "check  wind  sock"  operation 
involving  a  pilot  is  not  confused  with  a  "check  wind  sock"  operation  involving  an  air  traffic  control 
operator,  for  example. 
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First,  identifying  die  objects  and  the  operation  name.  Remember  that  the  operation  must 
follow  this  syntax  -  <verb  phraso  <object  name  or  component  name  as  direct  objeco  <rest>.  Since 
wind  sock  has  no  components,  only  "wind  sock"  may  be  used  as  the  direct  object 


WPUU  li>  «mta  Co*  vial  seek 

Tow  met  mw  specify  other  objects  needed  to  pnfon  tk*  operation. 

Tew  way  repeat  abject  types  —  which  iapli**  a  distinct  object  of  eaaa  type. 

XNMsaan«i  no  not  ntctitma  oompommts  or  "wind  sock" 

tan an  irua  conrunstT  onun  objbct. 

tl)  pilot 

121  aircraft 

(2)  aircraft  trla 

14)  aircraft  throttles 

|S|  aircraft  ms 

t<)  aircraft  external  power 

(7)  airoraft  eaflae 

Id)  airoraft  brakea 

ta)  airoraft  JOT 

tiO]  airoraft  UO  bleed  air 

111]  airoraft  UO  generator 

112]  wind  seek 

US)  buffar 

Cbooa a  one  or  aora  of  tha  above  or  "non*"*  1  2 


Mawa  tha  operation:  cback  triad  sock 


..next  the  intended  effect. 


Tbs  following  ere  the  allowable  iateaded  affects  t 
tl)  wind  eook  ie  ebacked 

t2]  wiad  seek  ie  not  ebacked 

Choose  owe  of  the  above*  1 


...then  the  preconditions.  You  identify  these  one  object  at  a  time... 

"he  following  are  the  allowable  preconditions  for  "pilot" 

til  pilot  is  cleared  to  deport 

121  pilot  ie  not  cleared  to  depart 

[3]  pilot  ie  cleared  for  taxi 

{41  pilot  ie  aot  cleared  for  taxi 

(3)  pilot  ie  cleared  for  takeoff 

14]  pilot  ie  aat  cleared  for  takeoff 

Choose  m  or  wore  of  the  above  or  “nona1  >  none 

The  following  ere  the  allowable  preeocditioaa  for  "aircraft'1 

tl)  aircraft  la  preflight  inspected 

12)  aircraft  is  aot  preflight  Inspected 

13]  aircraft  ia  at  tha  tazwiaal 

[41  aircraft  is  on  tha  runway 

t$)  aircraft  la  alrborna 

tf]  aircraft's  JOT  ia  off 

(7)  aircraft's  470  ia  oa 

It)  aircraft's  JOT's  gaaarator  ia  off 

It]  aircraft 'a  JOT's  gaaarator  is  on 

tlO]  aircraft's  JOT's  blaad  air  is  off 

til]  aircraft's  JOT's  blaad  air  ia  oa 

(12)  aircraft 'a  Iirakas  la  uachaekad 

113)  aircraft's  braksa  ia  eheekad 

Ill]  aircraft 'a  angina  la  off 

(IS]  aircraft 'a  angina  la  running 

(14 ]  aircraft's  axtcxaal  power  la  available 


126 


1X71  aircraft's  wt*ml  power  la  uaed 

tin]  aircraft ' a  external  power  ia  bypassed 

IX*]  aircraft 1  a  external  power  la  off 

1X01  aircraft' a  external  power  la  on 

MX]  aircraft' a  Wi  la  unchecked 

1X3]  aircraft  'a  MS  ia  cheeked 

13  J)  aircraft 'a  thxettlaa  ia  off 

tad]  aircraft ‘a  thxettlaa  ia  idle 

tat)  aircraft 'a  thxettlaa  ia  full 

tat]  aircraft 'a  trim  ia  unchecked 

t37)  aircraft 'a  trim  la  chaekad 

Cheoaa  om  or  more  of  tha  a beve  or  l<aio&a">  1 


since 

intended 


...similarly  the  side  effects.  (There  are  no  side  effects  possible  for  "wind  sock" 
there  is  only  one  property  set  for  it,  and  a  set  cannot  have  members  as  both  an 
effect  and  as  a  side  effect  Therefore,  "wind  sock"  is  skipped.) 


Tha  following  ara  tha  allowable  aida  af f act  a  for  "pilot" 
ti]  pilot  ia  elaarad  to  depart 
13]  pilot  ia  not  elaarad  to  depart 
O]  pilot  ia  elaarad  for  tari 
t«]  pilot  la  not  elaarad  tor  tarl 
IS]  pilot  la  elaarad  for  takeoff 
IS]  pilot  ia  not  elaarad  for  takeoff 
Chooae  one  or  more  of  tha  above  or  "noae">  none 
The  following  ara  tha  allowable  aide  attests  for  "aircraft" 

II)  aircraft  ia  preflight  inapeotad 

13)  aircraft  is  not  praf light  inspected 

IS)  aircraft  ia  at  tba  terminal 

Id)  aircraft  ia  airborne 

IS]  aircraft's  XPO  ia  off 

Id]  aircraft's  uo  ia  on 

17)  aircraft's  APU'a  generator  ia  oft 
Id]  aircraft's  AM's  generator  is  on 
19]  aircraft's  APU's  bleed  air  is  oft 

110)  aircraft's  UU's  bleed  air  is  on 

III]  aircraft's  brakes  ia  unchecked 

111)  aircraft 'a  brakes  la  cheeked 

US]  aircraft's  angina  la  off 

114]  aircraft's  angina  ia  running 

115]  aircraft's  external  power  ia  available 
lid)  aircraft's  axteraal  power  is  u«ed 
117)  aircraft's  external  power  la  bypaaaad 
lid]  aircraft's  external  power  Is  off 

119]  aircraft 'a  external  power  la  on 

130)  aircraft 'a  MW9  ia  unchecked 

tail  aircraft's  MM  la  chaekad 

[22]  aircraft's  throttles  la  oft 

tas)  aircraft's  throttles  is  idle 

tad)  aircraft's  throttles  ia  full 

taS)  aircraft's  trim  ia  unehaekad 

tad)  aircraft's  trim  is  chaekad 

Choose  one  or  more  of  tha  above  or  “none" >  none 

Operation  baa  bean  added  to  olass  "wind  sock". 

romu>» 
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use  of 


special 

show 


...you  will  note  that  creating  an  operation  is  a  very  wordy  process  --  but  because  of  the 
menus,  there  is  little  chance  for  error  and  little  typing  involved. 

The  second  example  is  with  the  pilot.  Because  pilot  is  a  character  object,  you  will  get  a 
message  which  describes  the  special  syntax  if  the  pilot  is  the  direct  object.  We  will  only 
the  execution  of  the  command  up  to  the  naming  of  the  operation. 


KKBUIIiD>  create  operation  for  pilot 

You  must  new  specify  other  ofcjutt  needed  to  perform  the  operation. 

You  may  repeat  object  type*  --  which  implies  e  distinct  object  of  same  type. 
IMPORTANT!  DO  NOT  INCLUDE  C0MP0NSNT8  OF  "pilot" 

UNLESS  IT  IS  A  COMPLETELY  SIFARATS  OBJRCT. 


[1] 

pilot 

Ul 

aircraft 

(32 

aircraft 

trim 

(4) 

aircraft 

throttles 

[52 

aircraft 

NWS 

[61 

aircraft 

external  power 

(72 

aircraft 

engine 

[8] 

aircraft 

brakes 

(»] 

aircraft 

APU 

(102 

aircraft 

APU  bleed  air 

[11] 

aircraft 

APU  generator 

[13] 

buffer 

[13] 

wind  so n'r. 

Choose  one  or  more  of  the  above  or  “none11*  2 

This  is  a  character  object.  If  itself  is  the  direct  object,  you  must 
use  the  form  "bave  <«bject>  <operation>"  where  <operatiou>  ia  not  null. 
Nnme  the  operation)  have  pilot  request  flight  clearance 
The  following  ere  the  allowable  intended  effects) 

...etc.... 


The  final  example  involves  the  specification  of  a  component  direct  object  This  will  be 
potentially  very  confusing  because  the  general  rule  for  where  to  place  an  operation  is  different  than  where 
to  place  a  property  set  in  a  composite  object  Operation  go  to  the  component  only  if  the  operation 
absolutely  dees  not  impact  the  whole  object.  For  many  of  the  aircraft  operations,  however,  many  of  the 
operations  changing  one  component  have  preconditions  involving  other  components.  Therefore,  the  below 
example  for  die  "engage  external  power"  operation  is  defined  for  the  aircraft,  not  the  aircraft  external 
power,  "external  power”,  however,  is  a  legal  direct  object  because  it  is  a  component  of  aircraft 


•OXU»  crests  operation  for  eirereft 
You  must  now  specify  other  objects  needed  to  perform  the  operetion. 

You  may  repeat  object  types  —  which  loplles  e  distinct  object  of  sene  type. 
IMPORTANT)  DO  NOT  INCLUDE  COMPONENTS  "aircraft" 

UNLESS  IT  IS  A  COMPLETELY  SEPARATE  OBJECT. 

[1]  aircraft  trim 

[3]  aircraft  throttles 

[3]  aircraft  NWS 

[4]  aircraft  external  power 

[5]  aircraft  engine 

[62  aircraft  brakes 

[7]  aircraft  APU 

[62  aircraft  AFU  bleed  six 
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(9]  aircraft  AFO  generator 
flO]  pilot 

[11]  wind  sock 

[12]  buffer 

[13]  aircraft 

Choeat  on*  or  more  of  the  above  or  ‘‘none">  10 

Him  tha  operation!  engage  aitarul  power 

The  follow log  ara  tha  allowable  intend ad  affaetat 

[1]  aircraft 'a  external  powar  ia  available 

[2]  aircraft 'a  external  powar  ia  uaed 

[3]  aircraft ‘a  external  powar  ia  bypaeaed 

[4]  aircraft 'a  external  powar  ia  off 

[5]  aircraft' a  external  powar  ia  on 
Chooaa  one  of  tha  abov«>  S 

Tha  following  ara  tha  allowable  preeonditioaa  for  "aircraft" 
(11  aircraft  ia  preflight  ina pasted 

[2]  aircraft  ia  not  preflight  inepected 

[3]  aircraft  ia  at  the  terminal 

[4]  aircraft  ia  on  tba  runway 

[51  aircraft  ia  airborne 

[6]  aircraft 'a  xj>n  ia  off 

[7]  aircraft ‘a  APC  ia  on 

[41  aircraft 'a  AFC  a  generator  la  off 

[9]  aircraft' a  AFC  a  generator  ia  on 

[10]  aircraft'*  AFC  a  bleed  air  ia  off 

[11]  alroraft'a  AFC  a  bleed  air  ia  on 

[12]  aircraft 'a  brakea  ia  unchecked 

[13]  alroraft'a  brakes  ia  checked 

[14]  aircraft 'a  angina  ia  off 

[15]  aircraft ‘a  angina  ia  running 

[14]  alroraft'a  external  powar  ia  available 

[17]  alroraft'a  external  powar  is  used 

[18]  aircraft's  external  power  is  bypaaaed 

[15]  aircraft 'a  Hire  ia  unchecked 

[20]  aircraft's  NWS  ia  checked 

[21]  aircraft's  throttles  is  off 

[22]  aircraft's  throttles  ia  idla 

[23]  aircraft's  throttlas  is  full 

[24]  aircraft's  trim  ia  unchecked 

[25]  aircraft's  trim  ia  ehackad 

Cboos*  one  or  more  of  the  above  or  "none"*  1 

The  following  are  the  allowable  precondition*  for  "pilot1' 

[1]  pilot  la  cleared  to  depart 

[2]  pilot  is  not  cleared  to  depart 

[3]  pilot  is  cleared  for  taxi 

[4]  pilot  ie  not  cleared  for  taxi 

[5]  pilot  is  cleared  for  takeoff 

[<]  pilot  is  not  cleared  for  takeoff 

Choose  one  or  aere  of  tha  above  or  “nono“>  none 

The  following  are  the  allowable  side  affeeta  for  "aircraft" 

(1)  aircraft  is  not  preflight  inspected 

(2)  aircraft  ia  at  tha  terminal 

(3)  aircraft  ia  on  tha  runway 

(4)  aircraft  is  airborne 

(5)  aircraft's  AFO  lu  off 

«)  aircraft's  AFD  is  on 

[7]  aircraft's  AFO's  generator  ia  off 

[8]  alroraft'a  AFO's  ganara&or  ia  on 

[9]  aircraft's  AFO's  bleed  air  ia  off 

[10]  aircraft's  AFD 'a  bleed  air  ia  on 

[11]  aircraft's  brakas  la  unchncked 
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(121  aircraft'*  br*k*i  ia  checked 

ti3]  aircraft ' ■  angina  ia  off 

114 J  aircraft'*  aagla*  ia  running 

(15]  aircraft 'a  external  power  ia  available 

116]  aircraft'*  external  power  ia  uaad 

(17)  aircraft'*  external  power  ia  bypaaaad 

(It]  aircraft'*  NWt  ia  unchecked 

(19]  aircraft 'a  NWS  ia  checked 

(20]  aircraft'*  throttle*  ia  off 

(21]  aircraft'*  throttle*  i*  idle 

(22]  aircraft'*  throttle?  i*  full 

(23]  aircraft'*  trial  i*  unchecked 

(24]  aircraft'*  trin  ia  chaekad 

Choose  one  or  acre  of  the  above  or  "non*“>  none 

The  following  are  the  allowable  aid*  effects  for  "pilot" 

(1]  pilot  ia  cleared  to  depart 

[2]  pilot  ia  not  cleared  to  depart 

(3]  pilot  la  cleared  for  taxi 

[4]  pilot  ia  not  cleared  for  taxi 

(5]  pilot  ia  cleared  for  takeoff 

[6]  pilot  is  not  cleared  for  takeoff 
Choose  one  or  nor*  of  the  above  or  "nona">  non* 
Operation  baa  been  added  to  elaaa  "aircraft". 

MBMXliD* 


Other  useful  commands  for  manipulating  operations  are  remove  operation ,  view 
operation,  and  modify  operation. 

e.  Review  the  Objects.  Once  the  objects  have  been  saved,  it  would  be  wise  to  review  the  objects 
before  going  into  the  task  definition  phase  using  the  WdH>  object  command.  This  will  also  help  show  you 
what  work  has  been  done  in  preparation  for  the  task  definition  phase. 

nnuzu»  dew  object  nanad  pilot 
Clase  "pilot"  la  alean 

Dependencies!  character 

Claae  "pilot"  ie  a  character  elaaa  with  suparolaaa (aa)  "character". 

Claas  "pilot"  haa  no  derived  oleaaes. 

Ccopoment*  of  class  "pilot" i 
<none> 

Property  Pets  of  Class  "pilot" i 

tl)  flight  clearance 

12]  takeoff  clearance 

(3]  texl  clearance 

Suuaary  Pacts  of  class  "pilot  “t 

<nena> 

Property  Display  Date  of  claas  "pilot" i 
«none> 

Operations  of  Class  "pilot"* 

(1]  have  pilot  request  flight  clearance 

(2]  have  pilot  request  taxi  clearance 

(3]  have  pilot  request  takeoff  clearance 
Operation  Display  Text  of  Claes  “pilot" t 
<noa*> 

Background  Change*  of  Claes  "pilot" x 
<nen*> 

HU0XU»  view  object  nanad  buffer 
Class  "buffer"  is  clean 
Dependencies!  prop 

Class  "buffer"  is  a  prop  class  with  superclass (as)  "prop". 
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Class  "buffer"  has  no  derived  cImmi. 

Cocponents  of  cXu>  "huffer": 

<none> 

Proparty  lata  of  Cless  “huffer" < 

[1]  engagement 

(2]  presence 

Hiausry  Pacta  of  olaaa  "huffer" i 
<none» 

Proparty  Display  Data  of  Claaa  "buffer" t 
<none> 

oparation a  of  class  "buffer" i 
tl]  engage  buf for 
(2]  disengage  buffar 

Qparation  Display  Tart  of  Class  "buffar" i 
<aona> 

Background  Changes  of  Class  "buffar" i 
<nona> 

MSBOXLD>  view  object  named  aircraft 
Class  "aircraft"  is  claan 

Dapanda&eiast  aircraft  trim,  aircraft  throttles,  aircraft  UK a, 

aircraft  axtarnal  power,  aircraft  engine,  aircraft 
brakes,  aircraft  APO,  and  prop 
Class  "aircraft"  is  a  prop  class  with  superclass (as)  "prop". 

Class  "aircraft”  bas  no  derived  claasas. 

components  of  class  “aircraft" i 

II]  "APO"  of  class  "aircraft  APO" 

[2]  "brakes"  of  class  "aircraft  brakes" 

13]  "angina"  of  class  "aircraft  angina" 

14]  "external  power"  of  class  "aircraft  axtarnal  power" 

[5]  "MWB"  of  class  “aircraft  MfS" 

((]  "throttles"  of  claaa  "aircraft  throttles" 

[7]  «trl*“  of  class  "aircraft  trim" 

!•]  "APO ' s  generator"  of  class  “aircraft  AFC  generator" 

[9]  "APO  *  a  bleed  air"  of  class  "aircraft  APO  bleed  air" 

Property  lata  of  Class  "aircraft" i 

II]  location 

[2]  APO ‘a  bleed  air's  awitah  position 

[3]  APO's  generator's  switch  position 

(4]  APO's  switch  position 

(5]  MHS's  cheek  status 

[(]  brakes'  check  status 
17]  engine's  running  status 

[4]  external  power's  switch  position 

[9]  external  power's  usage 

110]  prsflight  completion 

III]  throttles'  position 
(12)  trim's  check  status 

Hu— ary  Pacts  of  class  “aircraft"  t 
<aona> 

Property  Display  Data  of  class  "aircraft"! 

<none> 

Operations  of  Class  "aircraft" i 

tl]  check  NWI 

(2]  check  brakes 

(31  adjust  trim 

(41  shut  off  APO 

(51  taxi  aircraft 

t<)  max  throttles 

(7]  fly  the  aircraft 

(•]  start  APO 

(9)  conduct  prsflight  inspection  on  aircraft 
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(10]  engage  wears*!  power 

(111  atart  engine 

(13]  disengage  wtarsal  powar 

[13]  engage  *30' •  generator 

[14]  engage  kPO ' a  bleed  air 

Operation  Display  fart  of  class  "aircraft  "i 
<aou: 

Background  Changes  of  Claaa  "aircraft" t 
<none> 

MBMZU»  view  object  wasad  wind  aock 
class  "wind  sock"  is  sleas 
Oapaadanoias i  prop 

Clasa  "wind  sock"  ia  a  prop  claaa  with  auperclaaa (aa)  "prop". 
Claaa  "wind  aock"  haa  no  derived  classes. 

Cosmonauts  of  class  "wind  sock" i 
<nona> 

Property  Seta  of  Class  "wind  sook"i 

(1]  cheek  status 

Suosary  Pacta  of  class  "wind  sock"> 

<none> 

Property  Display  Data  of  class  "wind  sock": 

<none> 

operations  of  Class  "wind  aock”: 

[1]  check  wind  sock 

Operation  Display  Vest  of  Class  "wind  sock": 

<nooe> 

Background  Changes  of  Class  “wind  sock": 

<none> 

HB»0XLD> 
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TAB  3.  BUILD  THE  TASK 


Building  the  objects  is  actually  the  most  difficult  part  of  the  process.  Once  a  good  set  of  objects 
is  built,  building  the  task  takes  no  more  than  a  couple  of  steps.  The  process  basically  goes  as  follows: 

-  Naming  the  task  and  telling  MEBuilder  all  the  objects  in  the  task. 

-  Telling  MEBuilder  what  the  state  each  object  is  in  at  the  beginning  of  the  task  and 

what 

state  constitutes  the  completion  of  the  task. 

-  MEBuilder  generates  one  solution  to  the  task  and  saves  it  as  the  only  solution. 

~  You  tell  MEBuilder  what  other  solutions  are  allowed.  At  each  step,  MEBuilder  will 

ensure 

that  your  other  solutions  in  fact  work. 

The  first  three  are  all  accomplished  when  you  perform  the  create  task  command.  Here  is  how 
this  command  works: 

NIBOXLD*  create  task  named  prap  aircraft 

for  the  primary  actor,  chooaa  from  ona  of  tha  following t 

(11  character 

12]  pilot 

Chooaa  ona  of  tha  above > 


You  will  first  note  that  the  creme  task  command  will  ask  for  an  actor,  which  must  be  a  character 
type.  You  can  use  the  generic  "character"  or  specify  a  specific  character  type  that  must  be  in  the  task.  The 
only  options  are  those  loaded  in  the  session  --  so  ensure  you  have  loaded  all  your  objects  in  the  session 
fust.  We  will  select  "pilot". 

Chooaa  ona  of  eha  above*  2 

Liat  all  of  tha  otkar  object*  that  ara  required  for  thia  task.  Zf 
thara  must  ba  more  than  ona,  than  rapaat  that  itam.  Knaure  you 
chooaa  tha  aoat  panaral  object  availabla. 

II]  pilot 

(2]  buffer 

U]  aircraft 

14]  aircraft  trim 

[S]  aircraft  thzottlaa 

t<]  aircraft  mm 

[7]  aircraft  external  power 

18]  aircraft  angina 

t»3  aircraft  brakaa 

110]  aircraft  APU 

til]  aircraft  ATU  blaad  air 

tl2)  aircraft  APU  ganarator 

til]  wind  aock 

■elect  ona  or  nora  of  tha  above  or  "none"**  2  3  13 
Task  “prap  aircraft"  ia  now  defined. 

Mow  working  on  teak  "prap  aircraft". 

Sype  "quit"  to  return  to  MSBOZLB  preapt. 


For  the  follow-on  pert,  we  have  identified  that  we  need  a  huffer,  wind  sock,  and  an  aircraft.  Note 
that  naming  all  the  components  of  aircraft  are  unnecessary.  If  an  aircraft  and  an  aircraft  engine  are  listed, 
then  that  constitutes  a  hill  aircraft  and  a  separate  engine. 
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Also,  if  needed,  you  could  have  specified  a  second  pilot  or  multiples  of  any  other  object.  If 
multiples  of  an  object  are  specified,  then  they  are  referred  to  in  the  task  as  object,  objectl,  object2,  etc.  (In 
the  future,  this  will  be  changed  to  "second  object",  "third  object",  etc.). 

Now,  we  will  go  through  the  process  of  identifying  the  initial  conditions  and  the  objectives  of 
each  object  in  the  task.  When  you  do  a  create  task  command,  the  default  initial  conditions  are  the  first 
member  of  each  property  set.  For  sets  of  one  member,  constituting  the  X,  not  X  case  --  the  not  X  is  the 
default.  For  the  objectives,  the  default  is  the  last  member  of  each  property  set  and  the  X  case  holds  for 
single  member  set 

For  the  pilot,  the  defaults  are  OK . 

The  following  are  the  currant  initial  condition*  for  “pilot". 

Indicate  which  ones  you  want  changed: 

[11  pilot  la  not  cleared  to  depart 

(3)  pilot  ie  not  cleared  for  taxi 

13)  pilot  la  not  cleared  for  takeoff 

Chooae  one  or  acre  of  the  above  or  “none",  none 

The  following  are  the  current  objective a  "pilot " . 

Indicate  which  propertlea  you  want  changad. 

(1)  pilot  la  cleared  to  depart 

(3)  pilot  ia  cleared  for  taxi 

(31  pilot  ia  cleared  for  takeoff 

Chooae  one  or  atore  of  the  above  or  "noaa">  none 

...but  for  the  buffer,  we  must  make  a  couple  changes.  The  default  says  that  the  huffer  is  not 
present,  which  is  not  true.  What  we  do  is  identify  the  first  property  as  needing  to  be  changed.  We  select 
the  correct  property  and  then  continue  cm. 

The  following  ara  thw  current  initial  condition*  for  "huffar". 

Indicate  which  ona*  you  want  changad t 
tl)  huffar  la  not  praaant 

[3]  huffar  la  diaangaged 

chooae  ona  or  more  of  tha  above  or  "none"*  1 
Chooae  the  appropriate  new  initial  condition: 

(11  huffar  la  not  present 

[3]  buffer  ia  praaant 

Chooae  one  of  tha  abova>  3 
Indicate  which  one*  you  want  changed: 

(1)  huffar  is  praaant 

13}  buffer  is  disengaged 

Chooae  ona  or  nora  of  tha  above  or  "nona"»  non* 

Now,  for  the  objectives  we  ’will  change  one  of  the  properties  also.  The  huffer,  according  to  task, 
is  disengaged  when  the  task  is  finished.  Well,  let's  say  that  we  really  don't  care  what  condition  the  huffer 
is  in  so  we  will  declare  it  as  a  don't  care.  The  "is  immaterial"  option  is  the  one  we  want 

the  following  are  tha  currant  objectives  "huffar”. 

Indicate  which  properties  you  want  changad. 
tl]  huffar  is  praaant 

(31  huffar  ia  engaged 

Cbooaa  ona  or  aora  of  tha  above  ox  **none‘'»  8 
Chooae  tha  appropriate  new  objective) 

[1]  huffar  i*  disengaged 

(3)  huffar  ia  engaged 

(3)  buffer's  engagratant  la  lxaatarlal 

Cbooaa  one  of  the  above >  3 
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Indicate  which  propsrtis*  you  want  changed. 

(1)  buffer  in  present 

(3)  huffar '*  engagement  is  immaterial 

Chooa*  9H  or  mora  of  eh*  above  or  "nos*"*  none 

Don't  cares  in  the  objectives  are  not  printed  to  the  student  -  so  the  only  thing  that  the  student  will 
see  is  that  the  huffer  must  be  present  when  the  task  is  complete.  The  following  is  the  best  rule  for  deciding 
don't  cares  --  an  item  should  be  a  don't  care  if  it  meets  the  following  criteria: 

-  The  property  set  value  is  not  critical  in  defining  the  desired  end  result. 

~  The  property  set  value  will  only  serve  to  confuse  the  student  if  it  is  listed  (the 

objectives 

should  be  a  minimal  set). 

--  The  property  set  value  is  something  that  might  change  after  the  student  has  finished 

with  it. 

(For  example,  a  similar  task  might  be  set  up  such  that  an  agent  might  move  the  huffer 
to 

another  aircraft  after  the  student  is  through  with  it). 

The  initial  conditions  of  the  aircraft  are  the  default  --  no  changes  needed  (not  preflight  inspected, 
at  the  terminal,  APU  and  its  components  are  off,  brakes  unchecked,  engine  off,  external  power  available 
and  off,  NWS  checked,  throttles  off,  and  trim  unchecked).  We  will  now  skip  ahead  to  the  point  where  the 
objectives  of  the  aircraft  are  specified. 


Xadlcat*  vMch  properties  you  want  changed. 

Ill  aircraft  ia  preflight  inspected 

121  aircraft  is  airborne 

(31  aircraft's  aru's  switch  position  is  immaterial 

(4]  aircraft's  hPU's  generator '■  switch  position  is  immaterial 

15]  alraraft's  XPU's  bleed  air's  switch  position  is  lamatsrial 

[6]  aircraft's  brakes  are  cheeked 

(7]  aircraft ' s  engine  ie  running 

t4)  aircraft's  external  power's  usage  is  lsnatarial 

[9]  aircraft's  external  power's  switch  position  is  immaterial 

(10]  aircraft's  MWS  is  ohackad 
til]  aircraft's  t'  .ties  ara  full 
(13)  aircraft's  trim  is  checked 

Choose  one  or  sore  of  the  above  or  "none"*  none 


Numbers  3,4,5,8,  and  9  are  reasonable  choices  to  omit  from  the  objectives  because  the  pilots  main 
task  is  to  check  everything  and  get  the  plane  in  the  air.  The  APU  and  external  power  don't  tell  the  student 
anything  directly  perhaps.  One  could  argue  that  #1 1  could  be  omitted  as  well.  It  all  depends  on  what  you 
want  the  student  to  see  and  which  items  are  absolutely  critical  in  defining  the  final  objective  (such  as  #2). 

We  will  also  skip  the  wind  sock  (lC=not  checked,  OBJ=checked).  Once  the  four  objects  are 
completely  done,  we  then  enter  'bird  step  -  where  MEBuilder  attempts  to  find  a  solution.  Here  is  the 
one  it  found: 


Visas*  wait.... I  am  trying  to  solvs  tha  problem. . . 

Tbs  following  is  ay  first  attsapt  at  solving  th*  task. 

til  conduct  praflight  inspection  on  airorsft 

(3)  engage  aircraft's  external  power 

(3)  engage  buffer 

14]  start  aircraft's  angin. 
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15)  uturt  aircraft 1 •  APU 
(C)  aikffaga  aircraft1*  APU'r  generator 
17]  aagaga  aircraft's  APU'u  bleed  air 
!•]  have  pilot  request  flight  clearance 
19)  disengage  buffer 

110)  disengage  aircraft's  external  power 

111)  check  aircraft's  xwf 

112)  cheek  aircraft's  brakes 

113)  have  pilot  request  taxi  clearance 

114)  taxi  aircraft 

US]  have  pilot  request  takeoff  clearance 

IK)  check  wind  sock 

117]  adjuct  aircraft's  tria 

119)  chut  off  aircraft's  APD 

119)  stax  aircraft's  throttles 

120]  fly  the  aircraft 

Action  successfully  added  to  the  task. 

Action  successfully  added  to  the  task. 

Action  successfully  added  to  the  task. 

Action  successfully  added  to  the  task. 

Action  successfully  added  to  the  task. 

Action  successfully  added  to  the  task. 

Action  successfully  added  to  the  task. 

Action  successfully  added  to  the  task. 

Action  successfully  added  to  the  task. 

Action  successfully  added  to  the  task. 

Action  successfully  added  to  the  task. 

Action  successfully  added  to  the  task. 

Action  successfully  added  to  tJiu  task. 

Action  successfully  added  to  the  task. 

Action  successfully  added  to  the  task. 

Action  successfully  added  to  tha  task. 

Action  successfully  added  to  tha  task. 

Action  successfully  added  to  tha  task. 

Action  successfully  added  to  the  task. 

Action  successfully  added  to  the  task. 

What  the  "action  successfully..."  message  means  is  that  the  task  data  structure  is  now  set  such 
that  the  above  20-slep  procedure  is  the  only  solution.  We  know,  however,  that  this  is  not  the  case. 

IMPORTANT:  Troubleshooting  the  task  if  there  is  no  solution  found  or  the  solution  is  wrong.  Currently, 
MF, Builder  has  a  very  limited  capability  to  identify  specific  reasons  why  a  solution  cannot  be  found. 
Remedies  are  underway.  In  the  meantime,  here  are  several  steps  to  take  if  MEBuilder  does  identify  such  a 
problem. 

1.  Using  the  set  initial  conditions  or  set  objectives  commands,  reduce  the  scope  of  the  task  to  a 
specific  segment  (say,  step  (a)  in  the  original  task  description).  Locate  the  segment  in  which  MEBuilder 
cannot  find  a  solution  and  then  check  the  operations  in  that  segment. 

2.  Using  the  set  objectives  command,  remove  some  of  the  don't  care  conditions  and  name  a  hard 
value  as  an  objective.  Sometimes  a  don't  care  will  make  the  objective  unachievable. 

The  next  thing  that  happens  is  that  the  prompt  has  changed  to  the  following: 

tnJKiprap  *iroraft]> 
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This  indicates  that  you  are  now  in  the  Task  Ix»p.  There  are  different  commands  available  here. 
In  general,  you  can  still  use  many  of  the  view  commands  available  from  the  Main  Loop  to  query  about 
objects  and  some  of  the  attribute  items.  However,  you  cannot  manipulate  the  object  definitions  -  while 
you  are  in  the  Task  Loop  all  objects,  other  tasks,  etc.  are  frozen. 

Now,  the  first  thing  we  wilt  do  is  use  the  find  splits  command.  This  command  looks  through  the 
task  and  decides  if  and  which  operators  could  be  done  in  different  orders.  Cunently,  with  the  one  solution, 
the  task  dictates  that  the  request  for  flight  clearance  must  precede  the  disengaging  of  the  buffer  -  which 
we  know  not  to  be  the  case.  This  command  will  identify  this  and  propose  a  possible  change: 

[fUKiprar  aircraft] >  Clad  splits 

The  following  appear  unrelated  ud  could  bo  parallel! 

Sequence: 

til  kwt  pilot  rtgiut  flight  ol»uue« 

Sequence: 

tit  disengage  huffar 

(21  diaaagaga  aircraft's  external  powar 

tSl  check  aircraft' a  ms 

14]  shack  aircraft's  brakes 

Make  thus  parallel  sequences T  yes 

Tha  following  ia  tha  procedure  as  presently  defined.. 

(1]  conduct  preflight  inspection  on  aircraft 

(2]  engage  aircraft's  external  powar 

t3]  engage  buffer 

[4]  start  aircraft's  angina 

t5]  start  aircraft's  »g 

t*]  engage  aircraft's  APD's  generator 

17]  engage  aircraft's  APO's  blood  air 

(•]  all  of  these i 

{•a]  aubprocadurai 
(Sal]  disengage  huffar 

[tel]  diaaagaga  aircraft 'a  external  power 

ItaJ]  check  airaraft's  ms 

[Sa4]  cheek  aircraft's  brakes 

[tb]  subprocedure i 

[Sbl]  have  pilot  request  flight  clearance 
19]  have  pilot  request  taxi  clearance 

110]  taxi  aircraft 

til]  have  pilot  request  takeoff  clearance 

[13]  cheek  wind  sock 

[14]  adjust  airaraft's  trim 

(14]  shut  off  aircraft's  AFV 

tlS]  wax  aircraft's  throttles 
116]  fly  the  aircraft 

Now  look  at  the  task  construction.  The  steps  have  been  renumbered  such  that  step  8  now  consists 
of  a  "split"  ••  two  sequences  of  actions  that  must  be  completed  before  continuing  on.  So  step  8al  can  be 
done  anywhere  among  the  steps  in  8b  so  long  as  it  follows  7  and  precedes  8. 

Another  is  found 

The  following  appear  unrelated  and  could  ha  parallel! 
dequeues i 

tl]  have  pilot  request  takeoff  clearance 
Sequence i 

(1]  check  wind  aock 

[2]  adjust  aircraft's  trim 
Mike  th—  parallel  sequences?  yes 
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Vkt  (oUavlig  la  tk*  prooadur*  aa  praaaaely  dafiaad. 

11]  conduct  prat light  laapaetloa  aa  aircraft 

[2]  aapaga  aircraft' a  axtaraal  powar 

19]  aagaga  tuff ar 

til  atart  aircraft 'a  angina 

IS]  atart  aircraft 'a  A90 

|S]  sagas*  aircraft 'a  APO's  ganarator 

I?]  aaaas*  aircraft 'a  APO's  blaad  air 

(S)  all  of  thaaai 


[•a]  suhprocadurai 
(Sal]  diaaagaoa  huf far 
(Sail  diaaasas*  aircraft 'a  astaraal  power 
t**3]  chack  aircraft' a  MW* 

|Sa4]  chack  aircraft 'a  brakaa 
tab]  subproeadur*  ■ 

I  Mai)  have  pilot  requaat  flight  claaraaca 

It]  haw*  pilot  raguaet  taxi  clearance 

110]  taxi  aircraft 

(111  all  of  thaaai 

Ilia]  subproeadur* ■ 
dial]  chack  wind  sock 
dial]  adjust  aircraft's  trio 
[lib]  subprocadura i 

dlbl]  have  pilot  raquast  takeoff  claarauev 
112]  shut  off  aircraft 'a  AVU 

111]  max  aircraft'*  throttles 

[14]  fly  the  aircraft 

Thar*  are  no  possible  parallel  actions  remaining . 
[TASK I prep  aircraft] > 


At  this  point,  if  you  study  the  task  construction  you  will  notice  that  it  conforms  to  the  original 
task  specification  -  meaning  we  are  done!  Two  steps  and  that  was  it 

However,  we  all  know  that  some  task  constructions  are  not  quite  this  convenient  Therefore,  we 
will  demonstrate  some  of  the  other  common  options.  The  first  item  to  note  is  that  most  of  these  commands 
use  the  step  number  as  the  argument.  In  order  to  keep  up  to  date  on  step  numbers  --  use  the  view  task 
command. 

We  will  first  demonstrate  the  move  stop  command.  This  command  is  especially  useful  if  you 
need  to  move  a  single  step  into  or  out  of  subprocedures,  or  declared  it  as  an  unordered  action.  Let's  say  that 
the  "disengage  buffer"  operation  really  needed  to  precede  the  request  for  flight  clearance  -  we  can  move 
that  step  out  of  the  subprocedure  and  establish  it  at  step  8  --  the  split  becomes  step  9: 


[TAXKiprap  aircraft]*  asva  atap  nuabac  1*1 
Kara  ia  what  you  may  dot 

[1]  Laav*  it  aloa* 

[2]  Nova  it  out  of  aubpxocadura  to  la  front  of  it. 

[9]  Daclar*  it  doabl*  "aaytiaa*  bafora  "disangaga  aircraft'*  axtamal 
powar" 

Chocs*  oaa  of  th*  abova>  2 
Actios  aueoassfully  aovad. 

[TAJXiprap  aircraft]*  view  taak 

Th*  followisg  is  th*  pxocadur*  as  praaaatly  dafiaad. 

(1)  conduct  prafllght  iaapaetloa  oa  aircraft 

12]  aagaga  aircraft'*  axtaraal  powar 

[3]  angag*  huf far 

14]  atart  aircraft's  angina 

[$]  atart  aircraft's  APO 
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ttf)  ug*S*  tlmtft 1 1  MO'i  ganarator 

(7]  no*V*  •intact' ■  JUFO'a  blaad  ait 

til  disaagaga  but far 

tO  all  eS  tbaasi 

t9a]  aubproeadurat 

(fall  disaagaga  aircraft '■  asternal  power 
dal]  chaek  aircraft '•  Mira 

tCal)  chaek  aircraft '•  hr  aka* 

db]  itbprceiAmi 

(9bl]  have  pilot  raquaat  flight  clear anca 
tlO]  have  pilot  raquaat  taxi  elearaace 
till  tasi  aircraft 

till  all  of  thaaat 

til*!  oubproeadurai 
111 all  ohaek  wind  aoek 
I  Hal]  adjust  aircraft'*  trim 
tllfc]  *ubprocedure i 

tllbl)  have  pilot  raquaat  takaoff  clearance 
t 13 1  shut  off  airoraft'a  AtO 

(14]  mas  aircraft'*  threttlac 

(15]  fly  tha  aircraft 

snTOSKVXXO. . .plaaaa  wait . . .Dona 
ITMXtprep  aircraft]  > 

The  move  sup  command  is  invettible  as  well  -•  a  second  application  of  this  command  will  allow 
you  to  put  step  8  back  where  it  was.  Similarly,  if  you  use  the  third  given  option  to  make  the  step 
unordered  you  can  use  move  step  to  make  it  ordered  again.  The  important  thing  to  understand  about  this 
command  is  that  the  object  definition  restricts  vour  options  --  if  you  want  to  move  the  step  somewhere  that 
violates  the  object  definition  MEBuilder  will  not  let  vou. 

Let's  say  that  we  decide  that  we  really  didn’t  want  the  split  in  step  9  after  all.  The  combine  step 
command  combines  the  subprocedures  together.  The  arguments  must  be  the  first  step  in  the  two 
subprocedures  to  be  combined. 


(Thfktprap  aircraft]  >  eesbiaa  step  aunbar  9*1  with  9bl 
Combination  of  aubprocaduraa  aucaaactul. 

[WKipnp  aircraft]  >  vlav  taak 

Tha  following  la  tha  proeadura  aa  praaaatly  daflaad. 
tl]  coaduot  prafllght  laapactloa  on  aircraft 

[3]  aagaga  airoraft'a  axtaraal  powar 

(9]  aagaga  huffar 

[4]  start  aircraft's  angina 

[5]  start  airoraft’a  apd 

(Cl  aagaga  aircraft's  MU' a  gaaarator 

[7]  aagaga  airoraft'a  in's  blaad  air 

(•]  dlsaagaca  huffar 

19]  diaaagaga  aircraft's  axtaraal  powar 

CIO]  ohaek  aircraft's  wn 

(11]  ohaek  aircraft's  brakaa 

IXa]  hava  pilot  raquaat  flight  elaaraaea 

til)  hava  pilot  raquaat  tasi  elaaraaea 

[14]  tasi  aircraft 

tlS]  all  efi  thaaai 

[15a]  auhprcoadura i 
[ISal]  chack  wind  sock 
tlSal)  adjust  aircraft's  trim 
t 15b]  swbprocadurs i 

tlSbl)  hava  pilot  raquaat  takaoff  elaaraaea 
(14)  shut  off  aircraft's  AFU 
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II?)  MX  aircraft ' «  throttlaa 

[14]  tly  t)M  aircraft 


You  will  notice  now  that  the  request  for  flight  clearance  is  now  step  12.  Let's  say  that  we  wanted 
it  in  step  1 1  ahead  of  "check  aircraft's  brakes".  The  swap  stop  command  will  allow  you  to  swap  adjacent 
steas  X  and  Y  if  Y  does  not  have  to  follow  X  due  to  X  and  Vs  operation  definition.  For  example,  we 
cannot  do  18  before  17,  so  doing  swap  sttp  itumbtr  17  with  18  will  be  disallowed.  However,  reviewing 
the  operation  definitions  for  1 1  and  12  we  find  that  we  can  swap  them. 


tCAttiprep  aircraft]  >  *wap  stap  nuabar  11  with  13 
Combination  ot  subprocaduras  auccaaaful. 

[tUXipMS  aircraft]  >  viaw  task 

Ik*  following  is  tk*  pxcwte*  u  prssantly  daflnad. 

ID  conduct  prat light  in* paction  on  aircraft 

t2]  angaga  aircraft's  axtaraal  powar 

|S]  angaga  huffar 

(41  start  aircraft's  angina 

tS]  start  aircraft's  in 

If]  angaga  aircraft's  AM's  gsnsrster 

[71  angaga  slrcraft's  Ws  blaad  air 

[•]  disangaga  huf far 

[9]  disangaga  aircraft's  axtarnal  povn 

110]  chaak  aircraft's  MWS 

111)  hava  pilot  rsousst  flight  claarane-s 

till  ehaek  aircraft's  brskss 

US)  hava  pilot  raquaat  taxi  elaaranua 

[14]  taxi  aircraft 

[15]  all  of  thaaai 
[lSa]  subprocsdursi 

(lSall  ehaek  clad  sock 
(15a2)  adjust  aircraft's  trim 
[15b]  subproesdura i 

[ISbl]  hava  pilot  r aqua at  takaoff  clsarancs 
[1C]  shut  off  aircraft's  AN 

[17]  mx  aircraft's  throttles 
[14]  fly  tha  aircraft 

There  are  other  useful  commands  such  as  modify  slap  which  allows  you  to  add  preconditions  and 
side  effects  (especially  probabilistic  ones)  and  messages  that  are  valid  only  within  the  context  of  this  task. 
The  command  reference  guide  will  be  of  more  assistance. 


TAB  4.  BUILD  THE  LESSON 


Now  that  the  task  is  complete,  we  are  ready  to  build  the  lesson.  The  lesson  is  set  up  as  a 
workbook,  a  series  of  problems  relating  to  the  same  theme.  In  this  section  we  will  demonstrate  how  one 
can  set  up  three  problems,  where  problems  one  and  two  relate  to  the  two  halves  of  the  task  and  problem 
three  is  considered  a  comprehensive  test 

The  crtaU  Usso <i  command  behaves  in  a  similar  manner  as  crtaU  task  in  that  a  series  of  steps  are 
accomplished: 


~  Naming  the  lesson  and  identifying  the  cast  and  props 
—  Naming  the  tasks  to  be  used  in  the  lesson 

During  the  task  construction  phase,  you  were  referring  to  the  objects  by  type  name.  Now  you  are 
going  to  identify  objects  and  give  them  proper  names  ••  which  will  be  used  in  referring  to  the  lesson.  For 
many  simple  applications,  you  will  not  need  to  identify  any  fancy  names  tor  the  objects.  A  simple 
convention  is  to  use  "you"  for  the  role  of  the  student  and  "the  <object>"  for  all  the  objects.  But  sometimes 
spicing  up  the  affair  can  make  the  problem  more  fun  --  like  calling  the  aircraft  "Bouncing  Betty"  a  la 
World  WarU. 

The  important  thing  about  the  create  lesson  command  is  that  you  must  specify  the  entire  cast  and 
props.  As  you  create  problems  for  the  lesson,  you  will  name  objects  and  cast  members  not  included  in  the 
problem  (This  is  like  naming  the  entire  cast  for  a  film  and  then  leaving  out  some  members  in  each  scene). 

Here  is  a  script  run  of  the  create  lesson  command: 


XESUXU*  UMt*  lasaon  UMd  pilot  training  X 
Choon  all  ot  tbs  props  and  shmatwi  for  thn  lessen.  If  any 
are  ewitted  is  any  ot  tie  problawa,  you  will  opacity  thoaa  la 
tba  problea.  Choices  Cor  onawsnda  era  i 

add  new  X  —  add  a  Maker  of  object  type  #X 
reserve  itea  x  —  rewove  tx  Crow  the  current  list 
alaar  —  wipe  out  the  list  and  start  over 

quit  --  accept  the  liat  and  eo&tl&ua 

abort  --  abort  defining  tbs  laasoa 

These  ere  current ly  in  tha  lasson t 
<nons> 

liana  are  your  choices  Cor  addins  to  tba  Xaaao&i 
113  character 
12]  wind  eoek 
IS]  aircraft 

(4]  aircraft  trim 

[5]  aircraft  throttles 
t«J  aircraft  MM 

17]  alreraft  external  power 
1*3  alreraft  ansina 
(91  aircraft  brakes 
[10]  aircraft  in 
til]  aircraft  in  bleed  air 
112]  alreraft  in  generator 
IIS]  buffer 
114]  pilot 

CMT/p»ors»  add  aaw  14 

Siva  a  rows  far  tba  naw  pilots  captain  jack 

X  as  suae  “captain  jack1*  ia  a  singular  nawa.  Corraet7  [Tes/No]  yas 
These  are  currently  in  tba  lesson. 
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[].]  Characters  "captain  jack"  of  "pilot" 

Thai; a  are  your  choices  for  adding  to  tha  lessons 
tl)  oHataet'-r 

taj  wind  took 

[3]  airoraft 

(4)  airoraft  trim 

[$]  airoraft  throttlaa 
td]  aircraft  NWS 
(7]  airoraft  axtarnal  power 
16]  airoraft  angina 

[9]  airoraft  brakaa 

[10]  airoraft  AFO 

ill]  aircraft  AJO  bleed  air 
[13]  airoraft  APD  ganarator 
[13]  buffer 
(141  pile: 

CAJ6T/kkoys>>  tujd  now  3 

Oiva  a  nama  for  tha  new  airoraft>  tba  aircraft 

X  assume  '  tha  aircraft"  ia  a  singular  nasw  .  Correct T  [Yes /Mo)  yae 

Those  ara  currently  in  tha  lessens 

(1)  Character!  "captain  jack"  of  "pilot" 

[3]  Props  "tha  aircraft"  of  "aircraft" 

Theca  ara  your  choices  for  adding  to  tha  lessons 

[I]  character 
(2  ]  wind  sock 

[3]  aircraft 

[4]  aircraft  trim 

[51  aircraft  throttles 

[6]  aircraft  NWS 

[7]  aircraft  external  powar 
(61  aircraft  engine 

[91  aircraft  brakes 
[10]  aircraft  APD 

(II)  aircraft  APtJ  blaad  air 

[12]  aircraft  APU  ganarator 

[13]  buffer 

[14]  pilot 

CAST/FXOF8»  add  naw  13 

9ivo  a  name  for  tha  naw  buffer*  the  huffar 

.  etc.  as  we  add  the  other  items  (a  huffer  and  a  wind  sock),  we  get: 

These  ara  currently  in  tha  lessons 

[1]  Characters  "captain  jack"  of  "pilot" 

(21  Props  "the  aircraft"  of  "aircraft" 

[3]  Props  "tha  huffer"  of  "huffar" 

[4]  Props  "the  wind  Jock"  of  "wind  sock" 

These  are  your  choices  for  adding  to  tha  las sons 

[1]  character 

[2]  wind  sock 

(31  aircraft 

(41  aircraft  trim 

[5]  airoraft  throttles 

[<]  aircraft  NWS 

(71  airoraft  axtarnal  power 
(•]  aircraft  engine 

[9]  airoraft  brakas 

[10]  airoraft  APD 

(111  aircraft  APD  blaad  air 

[12]  airoraft  APD  ganarator 


[13!  buffer 
[141  pilot 
cxn/nu> m»  quit 

Now,  upon  reaching  (his  poim  you  will  be  asked  to  supply  the  tasks  to  be  used  in  the  lesson. 
Only  those  tasks  which  have  been  loaded  and  whose  required  objects  are  a  subset  of  the  cast  and  props 
listed  above  will  be  included.  In  this  exercise,  oniy  the  "prep  aircraft"  task  applies,  so  we  show  it. 

Whan  Hating  tha  teaks,  apaoify  tha  taaka  according  in  Cha  moat 

likaly  order  that  tha  student  would  apply  than.  Thia  will 

oatahliah  tha  daf ault  aeana  and  objectives  tor  tha  problsas. 

tha  following  loaded  taaka  ara  availahlai 

[11  prap  aircraft 

Chooaa  ona  or  aoro  of  tha  abova>  1 

Laaaon  “pilot  training  I”  ia  now  defined. 

Work  on  laaaon  now?  yaa 

Dow  working  on  loaaon  "pilot  training  1" . 

Typa  “quit"  to  raturn  to  MBSUILD  pro.  . 

[LUSOMtpilot  training  X]> 

Important:  Every  object  must  have  a  task  associated  with  it!  No  object  may  be  idle! 

Now,  note  that  the  prompt  has  changed  again.  Just  as  before  with  the  tasks,  the  create  lesson 
command  brings  you  into  the  Lesson  Loop.  Once  you  are  here,  the  things  to  do  are  the  following: 

-  Set  up  the  introductory  text  using  the  edit  lesson  intro  command. 

--  Set  up  the  problems. 

-  Compile  and  run  the  lesson  to  test  it  out 

We  will  skip  the  edit  lesson  intro  command  and  show  you  the  intro  we  put  in  using  view  lesson 

intro. 

tUISSOMipilot  training  Z]>  viatr  laaaon  intro 

Tha  following  ia  tha  introduction  tart  for  thia  laaaont 


PILOT  TRAIMIMOi  LISSOM  1 

Thia  laaaon  ia  the  firat  laaaon  in  flying  as  aircraft.  After  thia 
laaaon  you  will  ba  familiar  with  tha  proceaa  of  starting  tha  plana  and 
taking  off.  Tha  apacific  axilla  taught  in  this  laeson  arai 

(a)  Conducting  all  prsflight  chacks  and  inapactions 

(b)  Basic  cownni  oat  ions  with  tha  towar 

There  ia  ona  problem  is  tha  lassos,  a  eewgprahasaiva  teat  of  tha 
afcilla  daacribad  above,  flood  luak. 


Now,  we  are  ready  to  create  problem.  This  command  is  set  up  similarly  to  the  task  definition, 
first  you  verify  the  objects,  then  set  the  scene  and  goal.  The  difference  with  the  create  problem  command 
is  that  the  scene  and  goal  default  to  the  task's  initial  conditions  and  objectives.  If  an  object  was  involved 
with  more  than  one  task,  then  the  default  are  set  assuming  that  the  tasks  listed  were  given  in  the  order  of 
application. 
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You  will  be  asked  to  verify  the  cast  and  props  for  the  problem.  You  cannot  remove  any  cast 
member  -  you  only  option  is  to  change  a  cast  member  to  a  new  type.  The  new  type  m  ,  ’  be  a  derived 
object  type  of  the  one  given.  Therefore,  if  you  select  [1]  below,  then  there  must  be  a  derived  object  of 
pilot  loaded  into  the  MEBuilder  session.  If  no  such  types  are  loaded  in,  then  you  cannot  change  it. 

We  are  going  to  do  the  comprehensive  test  first  because  it  is  actually  the  easier  problem  to  create. 
Later  on  we  will  show  you  how  to  reader  a  set  of  problems. 

(UMBOm  pilot  training  x]>  ersata  problem 

Mam*  ths  now  problem>  Comprehensive  Taat 

Tha  student  will  play  tha  role  of  "captlan  jack". 

You  may  modify  tha  type  of  any  of  tha  objacta  by  aalaoting  ita 
index  below.  Tha  naw  type  muat  ba  a  derived  object  of  tha  currant 
type  and  rnuat  already  bo  leaded  Into  tha  aasalon. 

Tha  currant  eat  of  objects  aret 

[1]  Character)  "captain  jack"  of  "pilot" 

12)  Props  "the  aircraft"  of  "aircraft" 

[3]  Prop)  "the  huffer"  of  "huffar" 

U]  Prop>  "the  wind  sock"  of  "wind  sock" 

IS]  Accept  this  list  and  continue 
Choose  one  or  more  of  tha  above  or  "nona">  S 
Tha  currant  initial  setting  for  "you"  is 

based  on  tba  initial  conditions  of  task  "prap  aircraft" 

Tha  currant  objectives  for  "you"  is 

based  on  tha  objective*  of  task  "prep  aircraft" 

The  currant  initial  netting  for  "tha  aircraft"  ia 

baaed  on  tha  initial  conditions  of  task  "prap  aircraft" 

The  currant  objectives  for  "the  aircraft"  is 
baaad  on  tba  abj actives  of  task  "prop  aircraft" 

Tha  currant  initial  setting  for  "tha  huffar"  is 

based  on  tha  initial  conditions  of  task  "prap  aircraft" 

Tha  currant  objectives  for  "tha  huffar"  ia 

baaed  on  tba  objectives  of  task  "prap  aircraft" 

The  current  initial  setting  for  "the  wind  sock"  is 

baaad  on  tha  initial  conditions  of  task  "prap  aircraft" 

Tha  currant  bbjactivaa  for  "tha  wind  sock"  is 
based  on  tha  objectives  of  task  "prap  aircraft" 

How  working  on  problem  "Comprehensive  Taat". 

Type  "quit"  to  return  to  La a a on  Building  prompt. 

(PROS) pilot  training  Xil]> 

The  prompt  has  now  changed  again.  We  are  in  the  Problem  Loop.  In  this  loop,  we  can  adjust  the 
initial  scene  and  objectives,  or  view  them,  using  the  set  scene,  view  scene,  set  goal,  and  view  goal 
commands.  We  can  also  edit  problem  intro  and  view  problem  intro  for  the  problem's  introductory  text. 
The  view  problem  command  is  also  useful  here. 

tPROBtpilot  training  1)1] »  vlaw  problam 

Problem  il  of  lesson  "pilot  training  X" 

Mama  of  Probl*a»  "Comprehensive  Test" 

Baser lpt lea  of  Problem) 

Mew  that  you  have  successfully  eooplstad  tha  various  phase*  of  tha 
process,  let's  put  tha  whole  thing  together  from  tha  start.  Qood 
luck  I 


tPKOBipllet  training  X>1]» 
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Because  we  are  making  a  comprehensive  test,  the  task  and  problem  are  basically  the  same.  So  for 
this  problem  we  are  done.  The  quit  command  will  return  you  to  the  Lesson  Loop. 

[MO i pilot  training  x<l]>  quit 
[LSMOMt pilot  training  X]  > 

(Presently,  there  are  a  lot  of  enhancements  for  the  Problem  Loop  that  are  planned  but  not  yet 
implemented  —  some  of  the  enhancements  will  include  overriding  or  blocking  random  events,  changing 
some  of  the  frequencies  of  some  events,  etc.  etc.  These  are  in  the  works.) 

Next  we  will  create  the  other  two  problems.  We  will  have  the  first  problem  be  for  the  First  Half 
of  the  task,  defined  as  the  point  where  we  are  looking  to  leave  the  terminal  (which  is  after  the 
subprocedures  in  step  8).  We  will  create  the  problem  as  before,  but  now  we  will  invoke  the  set  goal 
command  for  each  object  and  tell  it  the  exact  point  in  the  task  where  we  want  to  end. 

[LMSONtpllot  training  x]>  create  problem  namad  pirae  Half 
The  atudant  will  play  tha  rola  of  "eaptain  jack" . 

You  say  modify  the  typa  of  any  of  tha  objaets  by  aalacting  ita 
index  balow.  Tha  naw  typa  must  ba  a  darivad  object  of  tha  currant 
typa  and  must  already  ba  loadad  into  tha  eeeeion. 

Typa  "none"  for  no  ehangaa. 

Tha  currant  aat  of  objaeta  arat 

£13  Character t  "captain  jack"  of  "pilot" 

[2]  Prop:  "B-10"  of  "aircraft" 

[3]  Prcpt  "tha  huffar"  of  "huffar" 

[4]  Prop i  "tha  wind  aock"  of  "wind  aock" 

[5]  ,  Accept  tha  liat  and  continue 
Chooae  one  of  tha  above>  5 

Thia  now  problem  la  number  2. 

. ate . . 

[PAOBt pilot  training  Z>2]>  aat  goal  for  captain  jack 
Thia  ia  the  currant  acenario  for  tha  object < 

[1]  captain  jack' a  flight  clearance  ia  immaterial 

[2]  eaptain  jack 'a  taxi  clearance  ia  iamaterial 

[3]  captain  jack  ia  cleared  for  takaoff 
Your  optiona  arat 

atop  --  Sat  tha  cbjactivaa  of  tha  object  to  that  of  a  given  atop 
in  a  taak. 

modify  —  Make  adjuatmenta  to  tha  currant  obj actives  of  tha  object 
start  over  —  Undo  all  changes  ia  this  c amend 
help  --  Prints  out  this  message 

quit  —  queries  to  aava  ehangaa  and  exits 

BBT  QQAL> 

You  are  now  in  a  special  loop  for  the  set  goal  command  (set  scene  has  a  similar  loop).  The 
option  you  will  normally  provide  is  the  step  option,  demonstrated  below: 

8BT  OOAL>  Step 

The  following  are  your  choices  t 


tl] 

Leave 

it  alone 

[2] 

As 

it 

locks 

after 

step 

1 

o£ 

taak  prep 

aircraft 

13] 

As 

it 

looks 

after 

step 

2 

of 

taak  prep 

aircraft 

[4] 

As 

it 

looks 

after 

step 

3 

of 

task  prep 

aircraft 

15] 

Aa 

it 

looks 

after 

step 

4 

of 

taak  prep 

aircraft 

[C] 

AS 

it 

looks 

after 

step 

5 

of 

taak  prep 

aircraft 

17] 

AS 

if. 

looks 

after 

atop 

6 

of 

task  prep 

aircraft 
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(Si  As  it  look*  after  etep  7  of  taak  prap  aircraft 

(91  Aa  it  look*  after  the  subprocedurse  in  S  of  taak  prap  aircraft 

(iO]  As  it  looks  aftar  atap  9  of  taak  prap  aircraft 

(Hi  As  it  look*  aftar  atap  10  of  task  prap  aircraft 

(121  As  it  looks  attar  tka  subprocedures  in  11  of  task  prap  aircraft 

[13]  As  it  looks  aftar  stsp  12  of  task  prap  aircraft 

(14]  As  it  looks  aftar  atap  13  of  taak  prap  aircraft 

(15]  As  it  looks  after  atap  14  of  task  prap  aircraft 

[16]  As  it  looks  at  tha  beginning  of  taak  prap  aircraft 
Choosa  eno  of  tha  above >  9 

Tha  currant  objectives  for  tha  object  iat 

[1]  captain  jack  is  cleared  to  depart 

(2]  captain  jack's  taxi  clearance  is  immaterial 

(3]  captain  jack's  takeoff  clearance  is  Immaterial 
jr  ooal>  quit 

Notice  what  the  objectives  look  like.  Everything  is  treated  as  immaterial  except  for  the  last 
change  to  the  object  made  in  the  task.  This  means  that  the  only  objective  that  will  be  shown  to  the  student 
is  that  the  student  must  be  cleared  to  depart  If  you  want  something  else  to  be  shown  to  the  student,  then 
you  can  select  the  modify  option  to  make  adjustments  -  but  be  very  careful  when  doing  so  otherwise  you 
may  make  the  problem  unsolvable. 

After  adjusting  the  pilot,  we  perform  the  same  adjustments  to  the  other  three  objects.  The  B-10 
aircraft  is  demonstrated: 

[FBOBipilot  training  Zi2]>  aat  goal  for  B-10 
This  la  tha  currant  aeanario  for  tha  abjaeti 
[1]  B-10'*  praf light  c oaplat ion  is  lnaatarial 

12]  B-10  la  airboma 

13]  B-10 'a  AFU'a  switch  position  la  immaterial 

[4]  B-10 'a  ABU's  ganarator's  switch  position  is  iamatarlal 

tS]  B-10's  APO's  blaad  air's  switch  position  is  iamatarial 
[6]  B-10 ' t  brakas'  chack  atatuu  ara  iaaaterial 

17]  B-10 'a  angina 'a  running  atatua  ara  immaterial 

14]  B-10 'a  axtamal  powar'a  uaaga  ia  inoatarial 

19]  B-10 'a  axtamal  powar'a  awltch  position  la  iaaatsrisl 

[10]  B-10 'a  MW's  chack  status  ara  immaterial 

(111  B-10 'a  throttles'  position  la  lasMtarial 

(12)  B-10 'a  trim's  chack  atatua  ara  immaterial 

Your  options  arai 

atap  --  Bat  tha  objectives  of  tha  object  to  that  of  a  glvan  step 
in  a  task. 

modify  —  Make  adjustments  te  tha  currant  objective*  of  the  object 
start  over  —  Undo  all  changes  in  this  ouammi  1 
halp  --  prints  out  this  massage 

quit  —  queries  to  save  changes  and  axita 

BBT  QQAL>  Step 

Tha  following  ara  your  choices i 

[1]  heave  it  alone 

[2]  Aa  it  looks  aftar  step  1  of  task  prep  aircraft 

IB]  As  it  looks  aftar  atap  2  of  task  prap  aircraft 

(4)  As  it  looks  aftar  step  3  of  task  prap  aircraft 

(5)  As  it  looks  after  step  4  of  taak  prap  aircraft 

(6]  Aa  it  looks  aftar  step  5  of  task  prap  aircraft 

(7]  As  it  looks  aftar  step  C  of  task  prap  aircraft 

(•]  As  it  looks  aftar  step  7  of  task  prap  aircraft 

[9]  as  it  looks  aftar  tha  aubprocaduras  in  •  of  task  p*ep  aircraft 

[10]  As  it  looks  aftar  stsp  9  of  task  prap  aircraft 

[11]  As  it  looks  aftar  stap  10  of  task  prap  aircraft 
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113]  JU  it  look*  aftar  tha  subprooaduras  in  11  of  cask  prop  aircraft 

til]  M  it  looks  aftar  stap  12  of  task  prap  aircraft 

(141  As  it  looks  aftar  stap  13  of  task  prap  aircraft 

IIS]  As  it  looks  aftar  stap  14  of  task  prap  aircraft 

IIS]  As  It  looks  at  tha  beginning  of  task  prap  aircraft 

Cboosa  oaa  of  tba  above >  9 

the  currant  objectives  for  tha  objaet  isi 

111  A-10's  prof  light  ecaplatlon  is  lmrterial 

(21  B-10 'a  location  is  isssatarial 

(3]  B-10 1 s  Abb's  switch  position  is  issatarial 

(41  A-lO's  Abb's  generator's  switch  position  is  i— starlal 

15]  ••10 ' s  Abb's  blsad  air's  switch  position  is  laaatarial 

[C]  B-10 'a  brakes  are  cheeked 

(71  *-10 'a  angina's  running  status  are  imsatarial 

(•]  S-10's  external  power's  usage  is  lnsatsrial 

[9]  *-10 'a  external  power  is  off 

(101  b-10's  ms  is  chocked 

(11]  *-10 'a  throttles'  position  is  isssatarial 

[12]  »-10's  trio's  check  status  are  immaterial 
SIT  QOAL>  quit 

Sava  changes  to  objectives?  yes 
abjective  nodif lest ion  completed. 

Objectives  sot  for  "B-10" 

Important-.  It  is  not  necessary  but  strongly  recommended  that  the  same  step  be  selected  for  all 
objects  if  possible.  Failing  to  do  so  could  have  Averse  consequences  (there  is  presently  no  way  to  do  this 
automatically). 

We  will  skip  the  rest  of  the  creation  of  problem  2  and  all  of  problem  3.  Problem  3  is  identical  in 
concept  except  that  the  set  scene  command  is  used  to  put  the  initial  scenario  fer  all  objects  to  the  end  of 
step  8  in  the  task  which  the  goals  are  left  alone.  Below  are  the  intros  for  these  problems. 

[PROBtpilot  training  Ii2J>  viaw  problem  intro 

Tba  following  i»  tha  introduction  taxt  for  this  laasont 

Taminal  brafllght  QParatioaa 

birat  <  wa  will  train  you  on  tba  procadura  for  handling  tba 
aircraft  whan  you  flrat  arrlva.  Your  job  la  to  atart  with  an 
aircraft  with  avarything  turnad  off  and  taka  it  through  tha 
initial  saguanca  of  chacka  and  gain  claaranca  to  dapart  tha 
taminal.  Good  luck.  Captain) 


[PROBtpilot  training  Zt2]>  quit 

[UiaaQMipilot  training  Z]>  work  on  problam  number  3 

Mow  working  on  problam  “Second  Bait" 

tbBOB i pilot  training  Zt3]>  viaw  prohlam  intro 

Tha  following  is  tha  introduction  taxt  for  this  lassoni 


Taxi  and  Takaoff  Procedures 

In  this  problam,  your  plana  is  now  reedy  to  Isavo  tba  taminal 
u>d  towar  has  granted  you  pomisjion  to  dapart.  Your  job  is  to 
taxi  tha  alroraft  to  tbs  runway,  par form  tba  last  sat  of  ebacka, 
and  fly  your  B-10  aircraft.  Pon't  forget  to  communicate  with  tha 
towsr.  Good  luck.  Captain) 
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IMtOBipilot  training  Zt3]>  quit 


Here  is  how  our  lesson  looks  with  the  view  lesson  command. 


(UU«OMt  pilot  training  X]>  view  lesson 
Lesson  "pilot  training  Z"i 


Caati 

captain  jack . .  pilot 

Propat 

>■•10 . aircraft 

the  hut  far . .  hat  far 

'  tha  wind  aock . wind  rook 

Preblaat  satt 


f X]  Cowpr ahana ive  Test 

111  Pirat  Half 
131  gocoad  Balt 
[UMMONipilot  training  1]> 

Obviously,  the  problems  are  not  in  the  correct  order.  We  now  wish  to  order  them  correctly.  The 
order  problems  command  is  used  for  this  purpose. 

[LSBSOM i pilot  training  X]>  ordar  problaaa 

Cheoaa  tha  raordarlng  of  tha  problems.  Your  input  oust  ba  an  exact 
permutation  of  tha  nunbara  of  tha  laft  of  aach  antry. 

IX]  Coaqtrahanaiva  Taat 
t3]  Pirat  Half 
[3]  Second  Half 
Haae  tha  naw  ordar>  or  331 
(LBSSOH t pilot  training  Z)> 

You  can  perform  another  view  lesson  to  see  the  reordering. 

Now,  once  we  have  completed  the  problems,  we  are  ready  to  compile  lesson.  This  command  will 
assemble  an  METutor-ready  file  which,  in  die  next  section,  will  be  demonstrated.  The  sequence  of  events 
of  this  command  are  --  check  the  integrity  of  all  the  objects,  tasks,  and  the  lesson  -  then  produce  the 
METutor  database.  The  integrity  checks  can  be  performed  ahead  of  time  using  the  check  object ,  check 
task,  and  check  lesson  commands.  Here  is  how  it  looks  (note  -  on  a  SPARCStationlO,  this  took  about  10 
seconds  to  do). 

tLBMOHipilot  training  I)  >  cccpile  lessen 
Checking  integrity  of  object  "wind  a oak" ■ • . .OK. 
chaeking  Integrity  of  object  "aircraft" ....OK. 

Cheeking  integrity  of  abject  "aircraft  trin"....0X. 

Checking  integrity  of  object  "airoraft  throttlea" . . . .OK. 

Checking  Integrity  of  object  "aircraft  ■KB1'.... OK. 

Checking  integrity  of  object  "airoraft  external  power" ... .OK. 

Checking  integrity  of  object  "airoraft  engine". .. .OK. 

Cheeking  integrity  of  object  "aircraft  brakes".  ..OK. 

Checking  integrity  of  object  "aircraft  XPU"....OK. 

Cheeking  integrity  of  object  "airoraft  APU  bleed  air".... OK. 

Cheeking  integrity  of  object  "aireraft  APU  generator". .. .ox. 

Checking  integrity  of  object  "hufftr" . . , .OK. 

Cheeking  integrity  of  object  "pilot". .. .OX. 

Cheeking  integrity  of  taak  "prep  aircraft" .. .OK. 

Translating  "reecawended_t"  Pacta  . OX 

Translating  "precondition^"  Paata  ... ...CX 

Translating  "delatepostcondition^t"  Pacta  . OX 

Translating  "addpostcondition_t"  Pacta  .....OK 
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"7T’  '-.Ti  '.  ■ 


Translating  " randohanga_t "  facts . OK 

Translating  "aiagular_t"  facts  . ox 

Translating  "plural_t"  facts . OX 

Translating  "apply_tMt_t"  facts . OK 

Translating  “delet»_tsxt_t "  facts  . OX 

Translating  "add„tert_t"  facts  . OX 

Coapilat ion  successful  and  narked  currant. 
CbSMOMipilot  training  X]> 


To  save  in  METutor  compiled  file  --  use  the  save  compiled  lesson  command.  The  compiled  file 
will  be  the  name  of  die  lesson  with  underscores  attached  with  an  .met  extension  (pilot_training_I.met). 
The  METutor  will  be  in  the  current  working  directory,  not  the  library  directory! ! ! ! ! 

The  remainder  of  this  appendix  shows  the  beginnings  of  an  METutor  session  run  from  within 
MEBuilder  using  the  run  lesson  command.  All  we  are  doing  here  is  showing  that  the  lesson  compiled 
properly  and  that  the  workbook  structure  translated  correctly.  See  the  next  section  for  a  detailed  execution 
of  the  lesson. 

tUUSOMiplloC  training  X]>  run  lassos 
Running . 

- - — ..... - - - - - ♦ 

I  Maana-Sada  Tutoring  System  —  Vara ion  29  (MS Tutor)  | 

- - - - - - - - — - - — - + 

I  by  Professor  Rows  sad  CPI  Oalvla,  Haval  PO  School  I 
♦ - - - — - - ........ - ...... - - 

Welcome.  The  Sana  of  this  laaaon  ia  "pilot  tralnlag  X". 


Welcome  to  Pilot  Training,  Part  X  Takaoff 


Tha  purpoaa  of  this  laaaon  ia  to  acquaint  you  with  tha 
basic  procaduraa  ia  taking  off  —  including  praflight  chacks, 
towar  ccacninicatioas,  and  takaoff  prooaduraa. 

Thara  ara  two  major  segments  of  tha  procaaa  —  those 
procaduraa  that  must  be  dona  at  tha  terminal  and  those  that 
are  done  during  tan.  and  takaoff.  The  first  two  problems 
will  train  you  on  tha  two  part#)  the  third  will  bring  it  all 
together  for  you  for  a  comprehensive  teat. 

flood  buck.  Captain 1 


There  are  3  problems  ia  the  laaaon. 

You  nay  "list"  tha  problaaa,  "view"  a  summary  of  a  problem, 
or  "do"  a  problem,  “help"  is  alao  available. 

MXTutor>  do  list 

The  following  ara  the  available  problems  ia  tha  laaaoni 

[1]  first  Saif 

12]  peeoad  Half 

IS]  Comprehensive  Test 

WXTutor*  do  problem  1 

bonding  and  checking  the  problem . please  wait ...  .Done. 

fROBUM  *1 


Terminal  Praflight  Operations 

Pirat,  wa  will  train  you  on  tha  procedure  for  handling  tha 
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aircraft  when  you  first  arrive.  Your  job  is  to  start  with  an 
aircraft  with  everything  turned  off  and  taka  it  through  the 
initial  sequence  of  cheeks  and  gain  clearance  to  depart  the 
terminal,  flood  luck.  Captain 1 


The  following  are  your  objectives i 

you  Mist  be  cleared  to  depart,  1-10 ' a  brakes  must  be  checked,  1-10 ‘s 

external  power  wist  be  off,  1-10* s  WfS  wist  be  cheoked,  and  the 
buffer  wist  be  disengaged 

The  following  is  the  current  situation i 

1-10  is  at  the  tanainal,  the  buffer  is  disengaged,  1-10 1  a  XPO  is  off, 
1-10's  engine  is  off,  1-10 'a  throttle*  are  off,  the  huffor  is 
prssont,  1-10' s  ms  is  unehseksd,  1-10's  brakes  era  unchecked, 

1-10's  trie  is  unehseksd,  1-10's  external  power  is  available,  1-10‘s 
APD's  generator  is  off,  1-10's  external  power  is  oft,  and  1-10's 
AID'S  bleed  air  is  off 

What  do  you  want  to  dot  quit 

NXTutor>  do  problem  2 

Loading  and  checking  the  problem . please  wait ... .Dona . 

PROBLEM  «2 


Taxi  and  Takeoff  Procedures 

Xn  this  problem,  your  plane  ia  now  ready  to  leave  the  terminal 
and  tower  has  granted  you  permission  to  depart.  Your  job  is  to 
taxi  the  aircraft  to  tha  runway,  perform  the  last  sat  of  checks, 
and  fly  your  B-lo  aircraft.  Don't  forgot  to  oowsunicata  with  the 
tower,  flood  luck.  Captain! 


The  following  are  your  objectives! 

you  wist  be  cleared  for  takeoff,  1-10  wist  be  airborne,  the  buffer  must  be 
disengaged,  and  the  wind  sock  must  be  checked 

The  following  ie  the  current  situation! 

1-10  is  at  the  terminal,  you  era  cleared  to  depart,  1-10  is 

preflight  inspected,  1-10's  ms  is  checked,  1-10's  brakes  are 
checked,  tha  buffer  is  disengaged,  1-10's  throttles  ers  off,  1-10's 
APO  is  on,  the  huffor  is  present ,  1-10 ' s  engine  is  running,  B-10 ' s 

trim  is  unchecked,  1-10's  external  power  is  aveileblo,  1-10's 
external  power  is  off,  1-10 's  APU's  generator  is  on,  and  1-10 's 
APO's  bleed  air  ie  on 

What  do  you  want  to  do?  quit 

MBTutora  do  problem  3 

Loading  and  checking  the  problem . please  wait. .. .Dona. 

P1DBLBM  #3 


Comprehensive  Test 

Wow  that  you  have  completed  both  phases  of  the  process, 
let's  put  the  whole  thing  together,  flood  luck! 

The  following  are  your  objectives ■ 

you  must  bs  cleared  for  takeoff,  1-10  must  be  airborne,  the  buffer  must  be 
disengaged,  and  tha  wind  eoek  must  be  ehaekad 

Tha  following  is  tha  current  situation! 
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*-10  la  at  tha  tarainal,  tha  huffar  la  diaaagagad,  1-10 • a  A»C  la  eft, 
B-10'a  aaalaa  la  off,  *-10'a  throttlaa  ara  off,  tha  huf far  la 
praaaat,  1-10 'a  mis  la  uachaokad,  B-10'a  brakaa  ara  uachaokad, 

1-10' a  trim  la  uachaokad,  1-10'a  axtarnal  povar  la  avallabla.  1-10 'a 
llO'a  gaaarator  la  oft,  1-10's  axtaraal  povar  la  off,  aad  1-10‘a 
!»'■  blaad  air  la  oft 

What  do  you  vast  to  do?  quit 

MTutor>  quit 

laturnad  to  NKBuildar, , . 

[Lis Soli pilot  train lag  X]> 
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TAB  5.  RUNNING  THE  LESSON  IN  METUTOR 

The  following  is  a  sample  run  of  the  lesson  in  METutor.  This  sample  ran  demonstrates  several  of 
the  commands  and  features  of  METutor.  The  METutor  session  is  best  ran  from  the  original  working 
directory. 

Key  item  to  notice  -  remember  the  "have  pilot  request  <x>  clearance"  operations?  Notice  that 
because  the  student  is  serving  in  the  role  of  the  pilot  that  the  "have  pilot'  portion  is  chopped  off  and  that  all 
references  to  the  pilot  are  in  second  person  form  in  order  to  put  the  student  more  into  the  scenario. 

>  -galvint/aabuild/MlTutor 
Maas  tha  lesson  file>  pllot_tralnlng_l .  Mt 

4 - ........ - ---- - ....... - 

I  Means-Bids  Tutoring  iyitta  —  Version  29  (K* Tutor) 

4.... .............. ....... - ............. — - — 

I  by  Professor  Row*  and  CPT  Calvin,  Naval  VO  School 

+ - - - — — - - - - 

Wslcom .  Tha  naan  of  this  laaaua  la  "pilot  training  X" . 


Walooato  to  Pilot  Training,  Part  X  Tafcaoff 


Tha  purposa  of  this  laaaon  is  to  acquaint  you  with  tha 
baaie  prooaduras  In  taking  off  —  ineluding  praf light  ehaeks, 
towar  nraswnn  lost  Iona,  and  takaoff  prooaduras. 

Thara  ara  two  ai]cr  eegnents  of  tha  prooaas  --  thosa 
prooaduras  that  Must  ba  dona  at  tha  taminal  and  thosa  that 
ara  dona  during  taxi  and  takaoff.  Tha  first  two  problaas 
will  train  you  on  tha  two  parts 1  tha  third  will  bring  it  all 
togathar  for  you  for  a  cooprahansiva  tast. 

flood  Luck,  Captaint 


Thara  are  3  prableas  in  tha  laason- 

Tou  nay  "Hat"  tha  problasts,  "visw  a  auanary  of  a  p  rob  last, 
or  "do"  a  problast,  "hsip"  is  also  availabls. 

Ml  Tutors  do  problan  1 

loading  and  ohacklng  tha  problan . plaata  wait ....  Dona . 

PkOILKM  «i 


Taminal  Praf  light  Oparations 

first,  wa  will  train  you  on  tha  proesdura  for  handling  tha 
alroraft  vbsn  you  first  arrlva.  Tour  job  ia  to  atart  with  an 
aircraft  with  avarything  turnad  off  and  taka  it  through  tha 
initial  asquenae  of  ehaeks  and  gala  elaaraaca  to  depart  tha 
taminal.  Qood  luek,  captain! 


Tha  following  ara  your  objectives  1 

you  mat  ba  cleared  to  depart,  B-10's  brakes  Must  ba  ehaeked,  1-10 ■  s 

external  power  mat  ba  off,  1-10 's  NWS  nust  ba  ehaeked,  and  the 
buffer  mat  ba  disengaged 

The  following  ia  tha  currant  situation r 

1-10  is  at  tha  taminal,  tha  huffar  is  diaangagad,  1-10 1  s  apc  is  off. 
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b-10* a  Mala*  i*  off t  b-10 'a  throttles  era  oft,  the  buffer  la 
peasant (  B-?Vb  MM  ia  unchecked,  i-10'a  brakes  ere  unchecked, 

B-10's  trim  la  unchecked,  B-10 'a  external  power  la  available,  >>10*8 
ATO' a  generator  la  off,  *-10 'a  external  power  la  off.  and  *-10 ' a 
Area  blaad  air  la  off 

What  do  you  <«ant  to  dor  help 


Tou  may  eater  as.  operator  or  one  of  these  apaelal  cewmaadat 
halp  --  print  thla  taxt 

quit  --  return  to  MtTutor  aw  in  laval 

w£*w  atata  --  pretty  print  a  the  currant  atata 

view  objaotlvaa  —  pro tty  print*  your  objectives 
qut  cy  oparator  <op*rator> 

—  print*  all  Information  about  an  oparator. 
query  objaot  <objaot> 

..  print*  oparator*  avallabla  on  an  object, 
query  foot  <objaet> 

—  print*  all  Information  about  a  fact  or  objaetlva. 
The  following  aro  tha  oparator a  avallabla  la  thla  lesson i 
II]  adjust  B-10 1  a  trim 

(2]  check  B-10 'a  HW8 

13]  aback  B-10 ' a  brakes 

Ul  cheoh  the  wind  sock 

(5)  conduct  praf light  Inspection  on  B-10 

(<]  disangaga  b-10 'a  external  power 

17]  disangaga  tha  buffer 

10]  engage  B-10 'a  APU'a  blaad  air 

[9]  engage  b-10 'a  APU'a  generator 

110]  engage  b-lO'a  external  power 

til]  engage  tha  buffer 

112]  fly  the  b-10 

[13]  max  B-10' a  throttles 

114]  request  flight  clearance 

[IS]  raquaat  takeoff  clearance 

[1C]  raquaat  taxi  clearance 

[17]  abut  off  b-10 'a  APU 

[It]  start  b-10 'a  APU 

[19]  start  b-10' a  angina 

[20]  taxi  b-10 


What  do  you  want  to  do?  conduct  praf light  inspection  on  B-10 
Tou  ohoae  to  conduct  praf light  inspection  on  b-10. 

OX. 

[1]  b-10  ia  now  pratlighe  inspected 

What  do  you  want  to  do?  engage  B-10 'a  external  power 
Tou  chose  to  engage  B-10 'a  external  power. 

OX. 

[1]  b-10 'a  external  power  la  new  on 

What  do  you  want  to  do?  engage  tha  buffer 
Tou  choaa  to  engage  tha  buffer. 


OX. 

[1]  tha  buffer  ia  now  engaged 

What  do  you  want  to  do?  raquaat  takeoff  claaranoa 
Tou  ehoaa  to  raquaat  takeoff  elaaranca. 
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That  action  requires  thatt 

tl]  you  aut  ba  cleared  for  taxi 

M]  *-10  mat  ba  on  the  runvay 

What  *0  you  want  to  dot  taxi  a- 10 
You  chose  to  taxi  *-10. 

Suit  action  requires  thatt 

(1]  yon  mat  ba  olaarad  tor  taxi 

What  do  you  oast  to  dot  raquait  taxi  elaaranea 
ton  oboaa  to  raquait  taxi  olaaraxea. 

that  action  raqniraa  that  t 

tl)  you  mat  ba  olaarad  to  d apart 

ID  a-10'a  brakaa  mat  ba  cbackad 

What  do  yon  want  to  dot  view  objaetivaa 
Ika  following  ara  your  objaetivaa i 

you  mat  ba  olaarad  to  depart,  x-10'a  brakaa  mat  ba  cheeked,  B-10‘a 

external  power  mat  ba  off,  1-10 'a  HWf  mat  ba  cheeked,  end  the 
buffer  mat  ba  diaangegad 

What  do  you  want  to  dot  query  feet  *-10 1  a  external  powar  ia  on 

The  following  operators  are  raoomanded  for  achieving  this  feeti 
(1]  engage  »-10 1  a  external  power 

What  do  you  want  to  dot  query  object  the  buffer 

The  following  can  ba  perforated  on  "the  buffer". 

*•  Operator  »  "engage  tha  buffer" t 

The  operator  ia  intended  to  aahiava  "tha  buffer  would  ba  engaged  ", 

'*  Operator  ■  "disengage  the  buffer" > 

The  operator  ia  intended  to  achieve  "the  buffer  would  be  disengaged  ". 

Whet  do  you  want  to  dot  query  operation  eback  the  wind  eock 
forty,  that  ia  not  a  valid  comaad.  riaasa  try  again. 

What  do  yen  want  to  dot  query  operator  cheek  the  wind  c  sockk 
The  following  ie  true  about  "aback  the  wind  eock"t 

**  The  operator  is  rsc emended  for  achieving  "the  wind  eock  is  checked  " 

**  the  operator  is  reeomended  for  achieving  "the  wind  eock  ie  checked  “ 

*•  The  precondition  for  the  operator  ie  "*-10  met  be  on  the  runway  and  the 
wind  eock  met  not  be  checked 

*•  The  poet  condition  for  tha  operator  is  while  "the  wind  eock  would  be 
checked  ". 

**  the  postcondition  tor  tha  operator  ie  ""  while  "the  wind  eock  would  be 
checked  ". 

••  the  postcondition  for  the  operator  ie  ""  while  "the  wind  seek  would  be 
checked  ". 

*•  the  postcondition  tor  the  operator  is  •"  mile  "the  wind  eock  would  be 
checked  ". 

Whet  do  you  want  to  dor  quit 
MKutor*  quit 
> 
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APPENDIX  D.  SAMPLE  DATA  FILES 

This  appendix  contains  examples  of  data  files  produced  by  MEBuilder  during  the 
session  scripted  in  Appendix  C.  Then  following  are  the  files  included  in  this  Appendix: 

Tab  1.  mebuild.lib  —  The  library  directory  file  produced  by  MEBuildLIB 
Tab  2.  pilotcls  --  The  definition  file  for  the  "pilot"  object. 

Tab  3.  aircraft.cls  -  The  definition  file  for  the  "aircraft"  object. 

Tab  4.  prep_aircraft.tsk  -  The  definition  file  for  the  "prep  aircraft"  task. 

Tab  5.  pilot_training._l.les  -  The  definition  file  for  the  "pilot  training  I"  lesson. 

Tab  6.  pilot_training_I.met  -  The  compiled  METutor  file.  Appendix  E  contains 
excerpts  of  a  script  run  of  this  file  in  METutor. 
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TAB  1.  LIBRARY  DIRECTORY  FILE 


. . . . . . * . . . / 

/*  MUhiildar  Library  Fila  —  Directory  of  Claaaaa  and  Laaaona  */ 
/•*•*•** . . . . ************ . */ 


»-  dynaakic 
i-  multifile 
i-  dynamic 


typa_of _prolog_f ila / 1 . 
type_of_prolog_f ila/1 . 

llbrary_cla*»_#ntry/4 ,  library_taek_entry /4 , 
library_Xaeioa_«ntry/5 ,  library_llnk/l. 


>-  aultiflla  library_claaa_antry/4 ,  library_taek_antry/4, 
library_laaaon_ant ry / 5 ,  llbrary_lliik/I . 


type_of_prolog_file( ‘NKBuilder  Library  Directory  Pila ' ) . 


/•  library_olaaa_antry/4  */ 

llbrary_oleaa_entry ( [aircraft, trim] , 1 ./lib/aircraf t_tri». cla', 
date (94, 6,26, 10, 56,35) , 

[prop] ) . 

llbrary_elaaa_antry ( [aircraft, throttlas] , • . /lib/aircraf t_throttla 
,cla', 

data (94, 4,26,10, 56,35), 

[prop] ) . 

llbraxy_claae_entry ( [aircraft , 1  HNS ' ) , ' . / lib/aircraf t_HNS . cla ‘ , 
data (94, 6, 26, 10, 56,35) , 

[prop] ) . 

llbrazy_claaa_cat ry ( (aircraft, external, power] , • . /lib/aircraf t_e*t 
sn«l_pawer.cle 1 , 

data(94,6,26,lC, 56,35) , 

[prop]) . 

libraxy_claaa_antry  ( [aircraft, angina] , ' , /lib/aircraf t„ angina, cla • 
data (94,6,24, 10, 56, 35) , 

[prop]) . 

llbraxy_cla»a_entry  ( (aircraft, brakaa) , • . /lib/aircraf t_brakaa. cla ' 
data (94, 6, 26, 10, 56, 35), 

(Prop]) . 

library„claas_antry( (aircraft, 'APO 1 .bleed, air) , ' . /lib/aircraft_XP 
_blaad_air . cla 1 , 

data (94, 4, 24, 10, 56,35) , 

[prop]) . 

llbraxy..olaaa_antry ( (aircraft,  'APD'  .ganarator] , 1 . /lib/alrcraft JU> 
.generator. cla' , 

data(94,6,24, 10, 54,35) , 

[prof]) . 

library.olaaa  .antry (pilot, 1 , /ltb/pllot.cla 1 , 
data(94, 4, 24, 11,4,34) , 

[obaractar]) . 

llbrasy.elaaa.antry ( [triad,  eook] , 1 .  /lib/wind„*ock.cla  * , 
data(94, 4, 26, 11,4.39], 

[prop] ) . 

llbrexy.elaas.aatry (buf far, • . /llb/buffav.cla * , 
data (94, 6, 36, 11, 9, 7) , 

(prcpl) . 


156 


libraxy_class_entry<  [aircraft,  •APU' J , '  . /lib/ai?craft_APtt.cls ' , 
date(94,6,26,13,S4,32) , 
t [aircraft, 'APO* .bleed, air] , 

(•iterate,  'WD 1  , generator) , 
prep]) . 

library_cla**_entry (aircraft, ' , /Xib/aircraft.cls • , 
date (94, 6,26, 15, 16, 54) . 

( (aircraft , trial , 

(aircraft , throttles] , 

(aircraft, 'NWS 1 ] , 

(aircraft , external , power] , 

[aircraft , engine } , 

[aircraft, brakes] , 

[aircraft ,  'WO 1  ] , 
prop] ) . 


/*  libraxy_.cesk_entry/4  */ 

library_task_entry ( [prep, aircraft] , 1 . /lib/prep_aircra£t.tsk' , 
date (94, 6, 27, 10, 46, 4) , 

( [wind, sock] , 
aircraft, 

[aircraft, trial , 

(aircraft, throttles] , 

[aircraft, •  mrs 1 ] , 

[aircraft, external, power] , 

[aircraft, engine] , 

[aircraft, brakes] , 

[aircraft,  W], 

[aircraft, 'APO' .bleed, air] , 

(aircraft, 'APD* .generator] , 
buffer. 

Pilot]). 


/*  library_lesson_entry/5  */ 

library_lesson_entry( [pilot, training, ] , • . /lib/pilot _training_X . les ‘ 
date (94, 6, 27, 11, 55,58) , 

[ [wind, sock) , 
buffer, 
aircraft, 
pilot] , 

[ [prep, aircraft] ] ) . 


/•  library_link/l  •/ 
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TAB  2.  OBJECT  DEFINITION  FILE  FOR  PILOT 


. . . . 

/*  NXBUilder  Claes  Definition  File  */ 

/ . * . * . * . * . / 


i-  dynamic  type_of_prolog_file/l. 


i -  multif ile  type_of _prolog_f lie / 1 . 

<-  dynamic  claee_def/2,  component  H ,  property_eet/4, 

property_dieplay_data/4,  relation/4,  daemon/ 6, 
operation/# ,  operation_dieplay_data/4 . 


i -  multifile  class_def/2,  component /4,  property_eet/4, 

property_dieplay_data/4,  relation/4,  daemon/ 6, 
operation/*,  operation_diaplay_data/4 . 


type_of_prolog_file( 'MXBuilder  Library  Claaa  Definition  File'). 

/*  olaae_def/2  */ 
clase_daf (pilot, [character] ) , 

/*  component /4  */ 


/*  proper ty_»at/4  '/ 

property_aat (pilot, (flight,  clearance] , 
oneof ( [ 1  cleared  to  depart ' ] ) , 
not_hideable) . 

property_eet (pilot , (taxi, clearance] , 
oneof ( [ 1  cleared  for  taxi ' J ) , 
not_hideable) . 

property_eet (pilot , (takeoff , clearance] , 
oneof ( [ 1  cleared  for  takeoff  1 ] ) , 
not_hideable) , 


/*  property_dieplay_data/4  */ 


/*  relation/4  */ 


/*  daemon/C  */ 


/*  operation/#  *7 
operation (pilot, [aircraft] , 

have, pilot , (request, flight, clearance] , 

m, 

(onCAFC1  'a 1  .bleed, air)  ] ) , 

1  cleared  to  depart 1 , 

((], 
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til). 

operation  (pilot, (aircraft J , 

have, pilot, (request, taxi, clearance] , 
t ('cleared  to  depart '1, 

[checked (brakes ) ] ] , 

* cleared  for  taxi 1 , 

CO. 

01). 

operation (pilot, (aircraft], 

have, pilot, (request, takeoff, clearance] , 
(('cleared  for  taxi']. 

Con  the  runway']], 

■cleared  for  takeoff ', 

((], 


/*  operationl_dieplay_data/4  */ 


TAB  3.  OBJECT  DEFINITION  FILE  FOR  AIRCRAFT 


/«****• . * . . . . . . . ....../ 

/•  MSBuilder  Class  Definition  Fila  */ 

/*••*** . * . . . 


i>  dynamic  typ._of_prolog_flle/l. 


1  -  multifile  typa_o£_prolog_£ ila /I . 

i -  dynamic  clase_def/2,  component /4,  property_set/4, 

prop«rty_display_dat»/4 ,  ralation/4 ,  daamon/6, 
operation/*,  operation_display_data/4. 


i-  multi  fila  alass_def /2,  component /4,  property_set/4, 

prop. rty_di.pl ay _dat a/4 ,  ralation/4,  daemon/ 6, 
oparation/4,  oparation_display_data/4. 


typa_of_proloy_f il. ( 'MSBuildar  Library  Class  Bafinition  Fila1)* 


/*  class_def/2  •/ 
cla.s_daf (aircraft, [prop 3 ) • 


/*  component/ 4  •/ 

component (aircraft,  [aircraft,  'AFC  ] ,  'AFC  , 
daf ault ) . 

component (aircraft, [aircraft, brakes] .brakes, 
default) . 

component (aircraft , [aircraft, engine] .engine, 
default ) . 

component (aircraft, [aircraf t, external, power] , (external, power] , 
default) . 

component (aircraft, [aircraft, 'WWfl 1 ] , 'MWS 1 , 

default) . 

component (air or aft, [aircraft, throttles] , throttles, 
default) . 

component (aircraft, [aircraft, trial , trim, 
default) . 


/*  property_set/4  */ 

property_aet (aircraft, (preflight, completion] , 
oneof ( [ 'prof light  inspected 1 ] ) , 
not_hida  abl e ) . 

ptop.rty_.et (aircraft , location, 

oneof(['at  the  terminal ' , ‘on  the  runway 1 , airborne 1) , 
not_hideable) . 


/*  property_displey_data/4  •/ 

/*  relation/4  */ 


/*  daeaoa/6  */ 
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/*  operation/*  •/ 

eperation(alxereft, [pilot, buf far] , 
aback,  •«»',[], 

( [off ( external, pow  ar) ] , 

[)]. 

checked  ('MW'), 

m. 

[], 

til). 

operation ( aircraft, [pilot] , 
eba  ok, brake*, [], 

[  [oheckedl  'MS 1 )  1 , 

(]], 

checked (brakes) , 

[[], 

[]]). 

operation ( aircraft, [pilot, [wind, sock] ] , 
adjust, trim, [] , 

[[], 

II, 

[checked] ] , 
checked (trim) , 

(C, 

{]. 

til). 

operation (aircraft, [pilot] , 

[shut, off 1 , 'APU' , [] , 

[ [checked (trim) ] , 

[ ' cleared  for  takeoff 1 ] ] , 
off ( 'APU' ) , 

[[], 

[]]). 

operation (aircraft, [pilot] , 
tasi, aircraft, [], 

[[], 

[ 1  cleared  for  taxi ‘ ] ] , 

■on  the  runway', 

([]. 

[)]). 

opsration(elreraft, [pilot] , 
max, throttles, [] , 

[ [off ( 'APO' ) ) , 

[ 1  cleared  for  takeoff ' ] ] , 
full (throttles) , 

[(), 

[])). 

operation (aircraft, [pilot] , 

[fly, the] .aircraft,  [] , 

[(full (throttles) ] , 

(II. 

airborne, 

[(], 

(]]). 

operation (aircraft, [pilot] , 
start, 'APO', [], 

[('preflight  inspected1 .running (engine)], 

m, 

oat 'APO' ) , 

ttl. 
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(33). 

opa rat ion (aircraft, (pilot] , 

t conduct, praf light,  inapaction,on] .aircraft, (3 , 
t ( 1  at  tha  tarminal * ] , 

(13. 

■prat light  inapactad', 

t(). 

03). 

operation! aircraft, (pilot] , 

angaga,  [ external, powar] ,  (] , 

(t'praf light  inapactad' 1 , 

03. 

on (external, power) , 

(t). 

(33). 

oparat ion (aircraft, (huf far, pilot] , 
at art, angina, (3 , 

(t'praf light  inapactad' 1, 

[angagad] , 

03, 

running (angina ) , 

((], 

(). 

(33). 

oparation (aircraft, (huffar, pilot] , 
diaangaga,  (external, power 3 ,  [] , 

((]. 

[diaangagadl , 

(33. 

off  (axtamal.powar) , 

It). 

(3, 

(33). 


/*  oparationwdiaplay_data/4  •/ 
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TAB  4.  TASK  DEFINITION  FILE  FOR  PREP  AIRCRAFT 


/■■••'•a....*..******..**..*...*.*.****..*.** . . 

/*  Mnuilder  Ink  Definition  File  •/ 

. . . . 


i*  dynamic  type_of_prolog_file/l. 

*-  multifile  type_of_prolog_f ile/1 . 

« -  dynamic  task/3,  initial_oonditions/3>  objactives/2,  stage/6, 

aotion/6,  unordered_act ion/2,  relation/3. 

«•  multifile  taak/3,  lnltlal_condl tlona/2,  objeotivea/2,  stage/6, 
action/6,  unorder ed_act ion/ 2,  relation/3. 


type_of_prolog_file( 'MKkuilder  Library  Taak  Definition  Vile'). 


/*  taak/3  «/ 

taakt [prep, aircraft] , [pilot. pilot] , 
[ [buffer, buffer] , 

(aircraft,  aircraft] , 

[ [wind, aock] , [wind, aock] ] ] ) . 


/*  initial_conditioaa/3  •/ 
inltial_conditiona (pilot, 

[not ( ' cleared  to  depart ' (pilot) ) , 
not ('cleared  for  taxi' (pilot) ) , 
not ( ' cleared  for  takeoff ' (pilot ) ) ] ) . 
initial_conditiona (buffer, 

[preaent (buffer) , 
dlaengaged  (buffer) ] ) . 
iaitial_coaditiona (aircraft , 

(not ( 'preflight  inapected' (aircraft) ) , 

'at  tbe  terminal' (aircraft) . 
off ( ' aireraf t ' ' a ' , 'XPO • ) , 
off ( 'aircraft ' 'a' , 'APU' .generator) , 
off ( 'aircraft' 'a' , 'APD ' 'a' .bleed, air) , 
unchecked ( 'aircraft' 'a ' .brake a) , 
off ( 'eiroratt ' '■' .engine) , 
available ( ' aircraft ' ' a ' , asternal , power ) , 
off ( 'aircraft' 'a' .external, power) , 
unchecked  ( '  aircraft "  a ' , '  ms  • ) , 
off ( 'aircraft' 'a' .throttles) , 
unchecked! 'aircraft ' 'a ' .trim)  ] ) . 
initial_coaditions ( [wind, aock] , 

[not (checked (wind, aock) ) ] ) . 


/•  objeotivee/2  */ 
objectives (pilot, 

[ 'cleared  to  depart ' (pilot) , 
'cleared  for  taxi ' (pilot ) , 
'cleared  for  takeof f ' (pilot) ]) . 
objectives  (buffer, 

[present (buffer) , 
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lavatorial  Chuf  far'  '•>l«agignut)]) . 
ob J actives ( aircraft , 

t'praf light  inspected' (aircraft) , 
airborne (aircraft) , 

lavatorial  ( 1  aircraft ' '« 1 ,  '  asp  "s',  switch,  position), 
i  — starlaK  'aircraft 1  's',  'ASP'  'a',  'generator'  'a' , switch, position) , 
lavatorial <  'aircraft1  'o' ,  'ASP'  'a'  .blood,  'air "s', switch, position) , 
ehackad ( ' aircraft ''s' , brakes ) , 
running (• aircraft ' 'a', angina), 

lavatorial) 'aircraft’ 'a'.artarnal, 'power' 's' , usage) , 
laaaatariaK  'aircraft'  'a'.artarnal,  'power'  ‘s'  .switch, position) , 
ehackad ( 'aircraft' 'a', ’MWS'), 
full! 'aircraft' 's' .throttles) , 
ehackad  ( •  aircraft  "s',  trim)  ] ) . 
objectives ( [wind, aocfc) , 

[ehackad (wind, sock) 1 ) . 


/•  stags/ 6  •/ 

stage (start , linear , none , linear , 

[), 

())• 

s t age (ql, linear, none, linear, 
[(start, 101,1] ] , 

(1). 

stage (q2 , linear, none, linear, 
[(ql, 102,1]), 

(]). 

stags (q3 , linear, none , linear, 

[(42,103,1]], 

(])• 

stage (q4, linear, none, linear, 
([<13,104.1]). 

(])■ 

stage (q5 , linear .none , linear , 
[[44,103,1]), 

[1). 

stage (gt , linear, none, linear , 
([gS.lOS.U], 
tJ). 

stage (417 , linear .none, joining, 
t  [jolnl,laabda,l]  ] , 
tl>. 

stage (ql3 , linear, none , linear, 
[(417,113,1]], 

m. 

stage (q!4 , end-split , qi5 ,  linear , 
([413.114,1]), 

13). 

stage (ql4, linear, none, linear, 
((414, US, 1]], 
UqM,aad,l))). 

stage ( j oin2 , linear , none , j olning , 
((414,117,1), [414,113,1]], 

( (414, and, 1)]) . 

stage (qlS , linear , none , joining , 

( [joins, lanbda, 11), 

S3). 

st*ge (414 , linear , none , linear , 
[(415, 114,1]), 

()>. 
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■teg* (ql9, linear. none, linear, 
UqlO,  119,1)), 

m. 

■tag* (don* , no-act Ions , bob* , linear , 
ttqi9, 120,1)], 
tl>. 

■tag*  (  joi&l ,  linear,  BOB*  ,  j  OiBiBff  , 
t [q20, 109, ll.tqll, 112,1)]. 

[ lq20,and, 1] ) ) . 

■tag* (qll, llaaar , bob* , liaaar , 
ItglO,lli,m, 
t  tq20,and, 1] ) ) . 

•tag* (q2  0 , and- split , ql? . liaaar , 
t[qC,107,D), 

m. 

■tag* (qlO , li&aar , bob* , liaaar , 
[[q21, 110,1]), 

[(q20,aad,l])>. 

•tag*(q21, liaaar, Bona, liaaar, 
t(q20, 109,1)), 
tlq20,aad,l])) . 


/•  act ion/ 6  */ 

action! 101, conduct (preflight , inspection, oo, aircraft) , 

t), 

E), 

[), 
in¬ 
action  (102,  engage!  'aircraft'  .external, power) , 

I). 

C). 

U. 

in- 

act ion (103, engage (huffer) , 

n, 

[), 

o. 

n>. 

action(104, start ( 'aircraft ' ' a ' , engine) , 

t), 

I). 

(), 

m. 

action ( 105 , start ( ' aircraft ' ' a 1 , ' APO ' ) , 

[). 

n, 

El, 

0). 

action! 10*, engage! 'aircraft 1 '•' , 'APO' '•* , generator) , 

[). 

I). 

0. 

[))• 

action ( 107, engage! 'aircraft' 'a' , 'APO' '• ' , bleed, air) , 
(). 
t), 

[). 

()>. 

action ( 108 , have (pilot , request , flight ,clearance ) , 

I), 
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t). 

I), 

tJ). 

aotion(109,dioanaaga (huf tar) > 

tl. 

(I. 

tl, 

13) . 

action! 110, dicongagot 'aircraft' '■' , external, powar) , 

(1, 

11, 

t], 

m. 

action (111, chock! 'aircraft' 'o' , 'NWS' ) , 

(], 

tl. 

0, 

m. 

action! Ill, chock ( 'aircraft' 'a' ,brakao) , 

[], 

tl. 

t), 

(1). 

act ion (113,  have (pilot ,raqueet, taxi, claaranca) , 

(1, 

(1, 

0, 

tl). 

action (114, taxi (aircraft) , 

(1, 

tl, 

t). 

tl). 

action ( 115 , hava (pilot , lequeet , takoof f , cloaranco ) , 

11, 

(1, 

tl. 

0). 

action ( 11< , chock (wind, cock) , 
tl. 
tl, 
tl, 

0). 

aetion(117,&djuet  ( 'ail croft • 'o' .trim) , 

tl, 

0. 

(1, 

tl). 

action ( 118, ohut (off , 'aircraft' 'o' , 'ATO' ) , 
tl. 

0. 

tl. 

(1). 

action  119, next  'aircraft'  'o' .tfcrottlee) , 
tl, 

0, 
tl, 
tl)  • 

aetiontUO,  fly  (the, aircraft) , 
tl, 
tl. 
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(1. 

()>. 


/*  unord»r«d_*ot lon/2  •/ 

/*  r»l«tion/3  •/ 
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TAB  5.  LESSON  DEFINITION  FILE  FOR  PILOTJTRAINING 


t*  MDuildar  Lesson  Definition  Vila  •/ 

. . . . . 


>-  4ya«aio  type_of_prolog_file/l. 

i-  multifile  type_of_prolog_file/l. 


<-  dynamic  lesson/4,  lesaon.intro/1,  problem/ 5,  problem_intro/2, 

lnitial_*ettiag/3,  objectives /3,  aide_effect_override/S- 

i-  multifile  laaaoB/4.  leaaon.lntro/1,  problem/ 5,  problem,  intro/2 , 

lnitiel_settina/3,  objectlves/3,  eid»_e££ect_override/a , 


type_o£_prolog_file ( 'KXBuilder  Library  Lessen  Definition  Vila')* 


/*  lea son/4  •/ 

lesson l [pilot , training, <  j • J , 

[ [ [captain, jack , pilot , default ] ] . 

[ [ 'h-10 * , aircraft .default) , 

[ (the.huf f er) .buffer .default) , 

[ [the, wind, aock) , [wind, Book) .default]] , 

( [prep, aircraft ] } ) , 

/*  lssson_intro/l  •/ 

.’esaon_  intro  (  'Wslcoaae  i  o  Pilot  training.  Part  Z  Takeoff), 

lea  aon_int  ro ( ' 1 ) . 
lesson_iutro ( • 1 ) . 

leason_xntro( •  the  purpose  of  this  lesson  is  to  acquaint  you  with  the'). 
leaaonL.intro( 'basic  procedures  In  taking  off  —  including  preflight  checks,'). 
loason_intro  i '  tower  comunieations ,  and  takeoff  procedures.'), 
lee son. intro ( ' ' ) . 

lesson_intro ( '  i'here  airs  two  najor  sagaaente  of  the  process  —  those  ■). 
leeson_intro( ‘procedures  that  must  be  done  at  the  terminal  and  those  that'). 
le*son.intro( 'are  dene  during  taxi  and  takeoff.  Ths  first  two  problems ' ) . 
lessen. intro ( 'will  train  you  on  the  two  parts j  the  third  will  bring  it  all'). 
li-sson_intro( '  together  for  you  for  a  comprehensive  test.'). 
lesson_intro( 1 1 ) , 

lesson_intro ( '  Good  Luck,  Captain I'). 


/•  problem/ 5  */ 

pxoblea(2, [ 'Second' , 'Self ' ] , (captain, jack] , 

[ [ (captain,  jack) .pilot, default] ] , 

[ ( 'h-10 1 .aircraft, default] , 

[ [the, buffer] , buffer, defeult] , 

[ [the, wind, eock] , [wind.eock] .default] ] ) . 
problem  (3 ,  [  'Comprehensive' ,  'Test'  ] ,  (ceptein,  jack) , 
[ [ (captain, jack) .pilot .default] ] , 

[ [ '*-10 • .aircraft, default) , 

[ [the, buffer) .buffer, default] , 

[ (the, wind, seek) ,  [wind.eock]  .default]  ] ) . 
problend,  [  'first' ,  'Balt ' ) ,  [captain,  jack] , 

[ [ (captain, jack] .pilot , default] ] , 

[ . '8-10 ' .aircraft, default] , 
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t  [the,  buffer] ,huf f sr.defsult) , 

([the, wind, sock] , [wind, sock] .default)] ) . 


/*  probl«m_i»tro/2  •/ 

|Wl)l«Lt»tlot>i  'Taxi  and  Takeoff  Procedural'  )  , 
problem,  intro ( 3 , 1  •) . 

pwMwLiitialli 1  Za  this  problem,  your  plane  ii  bow  ready  to  leave  eba  terminal') 

problem-intro ( 2 , ' and  tower  has  gristed  you  permission  to  depart.  Tour  job  is  to'). 

problam_intro ( 3 , ‘ taxi  the  aircraft  to  the  runway,  perform  tbe  last  set  of  checks,  •). 

problem-intro  (3,  'and  fly  your  P-10  aircraft.  Pea' 't  forget  to  communicate  with  the') 

problem-intro ( 3 , ' tower .  Good  luck,  Captain! 1 ) . 

problem-intro  (3,  " ) . 

problem-intro (3,  'Ceaprehensive  Test ' ) . 

problem- intro ( 3 ,  " ) . 

problem- intro (3, '  Mow  that  you  have  completed  both  phases  of  the  process, 
problem- intro (3, 'let' '■  put  the  whole  thing  together,  oood  luck!'). 
problem_lhtro (1, 'Terminal  Preflight  Operations ' ) . 
problem-intro (1, ' ' ) . 

problem_intro ( 1, '  First,  we  will  train  you  on  the  procedure  for  handling  the’). 
prablsm_intrc(l, 'aircraft  when  you  first  arrive.  Your  job  is  to  start  with  an>). 
problem-intro  (1.  'aircraft  with  avsrythiag  turned  off  end  take  it  through  the'). 
problem_intxo(l, 'initial  sequence  of  cheeks  and  gain  clearance  to  depart  the'), 
problem-intro ( 1 , ' terminal .  flood  luck,  Captain! •). 
problam_lntro(l, ' ' ) . 


/*  initial_aettina/3  */ 
initial-setting (3, (captain, jack! , 

('cleared  to  depart' (captain, jack) , 
not ('cleared  for  taxi' (captain, jack) ) , 
not ( 'cleared  for  takeoff • (captain, jack) )]) . 
initial-setting (2, '1-10 • , 

(ahaoked(  'B-10  "s'  .brakes) , 
off  CP-10'  's', external, power), 
cheeked ( 'B-I0"a' ,  'HWS* ) , 

'preflight  inspected' ( 'P-10 ' ) , 

•at  the  terminal'  C»-10'), 
on('k-lO"s','JLPO'), 
on( ' »-10  "s',  'AFC "s'  .generator) , 
on( '»-10' ' i • , 'APO ' -a '.bleed, air) , 
running;  'B-10'  '#'  .angina) , 
available ( 'k-10' 's' .external, power) , 
off  ( '  B-10  "s',  throttles ) , 
unchecked ( 'B-10  "s',  trim)  ] ) . 
initial-setting (3, [the, buffer) , 

[disengaged (the, buffer) , 
present (the, buffer) ] ) . 
initial-setting (3, [the, wind, sock], 

[not (oheakad (the, wind, soek) ) ] ) . 
initial— setting (3, (captain, jack) , 

[not ( ' cleared  to  depart ' (captain, jaok) ) , 
not ( 'cleared  for  taxi' (captain, jack) ) , 
notfeleared  for  takeoff '  (eeptain,  jack) )]) . 
initiel_aetting(3, 'B-10' , 

[not ( 'pref light  inspaotad ' ( 'B-10 ' ) ) , 

'at  the  terminal '( 'B-10' 1 , 

off  CB-10"s'.  'APO'  ), 

off  ( 'B-10 "s',  'APO "s'  .generator) , 

off  ( 'B-10  "s',  'APO "s'  .bleed, air) , 

unchecked! 'B-10* 's' , brakes) , 
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off  CB-10'  'I'tOglat), 

available  ( 1 B-10 1  's', external, power) , 

off  CB-10'  'a*, external, power) , 

off ('B-10'  'a'  ,tlizattlss) , 

WotuluJ  { *P-X0  ’s' ,  trial  ] ) . 
lmitlal_>ettiae(l, (the.haf taxi . 

[preee*t(  the, belter) , 
dlsoagap«4(tha,hatf ar) ) ) . 
isltiaO*ttu«l),  ttk*,aladiM«kl , 
taoc (cheeked (the .wind,  took) ) 3 ) . 
lnltlel_eettia*d,  (captain,  lack) , 

(act ( 'clear ad  to  depart*  (obtain,  jack)  1 . 
wot ( 'a leer ad  for  taxi' leapt ala, jack) ) . 
not ('cleared  for  takeoff  *  (eaptala,  jack)  1  ]) . 
iaitial.settiae  d, '*-10 • , 

taot  ( 'prof  light  iupeeted'  ( **-10 ' ) ) , 

•at  the  terminal' ( '*-10*1 , 
off ('*-10' *a*, ‘*ra*), 
off {'B-10'  'a*.  W  's' .penerator) , 
elf  CB-10"*',  'hPO* 1  a '  (bleed, alt ) , 
unchecked ( 'B-10 1 ‘s' .brake a) , 
off  CB-10'  'e’,eapixe), 
available ( *B-10‘ ‘a* , art areal, power ) , 
off  CB-10'  ‘a*  .external,  power) . 
unchecked!  'B-10  "a ' .  *MIB' ) , 
off ( 'B-10 ' ' a throttle* ) , 
unchecked ( 'B-10' 'a' ,crle) 1 1 . 
inltial_settiaed. I the. buffer  ] , 

(peasant  (the, buffer) . 
dl stop sped (the. buffer) 1 ) . 
ialtial_eettlnp(l. (the, wind, sook] , 

thot (ohs-hed (tbs, wind,  sock) ) 1 ) . 


/"  objective# /I  •/ 
ftVJectiVNl},  tcapteia.  jack) . 

(lanet axial (oaptaia, 'jack' •#■ .flight, clearance) , 
(■aterUltsaptala.  'jack '  •« '  , text, clearance) , 

‘cleared  for  takeoff ' (captain. jack) 1 1 . 
t  ‘.jootiwes  (3,  'B-10 ' , 

Uanteriil  I  'B-10'  *3  '  ,pre  flight  .couplet  iool , 
airboma  CB-10). 

Jamaterial CB-10*  •#',  m  'a'  .switch, position > . 

I, Material ( ‘B-10*  ’a',  'JUT?'  'a* ,  'faaaTator '  ‘a ' .switch, position) 
(material  ( *B-10‘  'a' ,  'hfU'  'a'  .blued,  'air'  ,A«ite)i,  position) , 

iksuet axial ( 'B-10'  'a*,  'brakes '  * '  check, status) , 

(materiel CB-10'  'a',  'eealac  'a*  .ram tap, status) , 
imaterlal ( ‘B-10 ‘  'a', external,  'power'  's'  .usage) , 

(material ( 'B-10' •«' .external,  'poser'  •#•  .switch, position) . 
IxaMtertel CB-10* 'MB'  'a' , ehaek.atat.ua, . 

ImtsrUl CB-10'  'a',  'throttles'  " .position) , 
laaasteriel CB-10*  's',  'trim*  ‘a  .check,  statu*}) ) . 
ubjwcti-eail,  (the, huff er ? , 

(ixmtaflnltthe,  ‘hotfter '  .presence) , 
diaenpaaeditka.huftar)  ’  .1 . 
objectless  £3.  (tha.vind.so.*] , 

[  check ad ( the ,  wind . eoe  t ) 1 ) . 
object!  vend.  |enui».j«rb), 

£  iawterUl  (captain,  'leek'  ‘a* ,  flight  .clearance) , 

(materiel  (eaptnln, ' .aok'  'a'  .taxi, clearance) . 
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'cleared  far  takeoff '  (captain,  jack)  ] ) . 
objectives (3 , 'B-10' , 

(iiwatarial  ( 'B-10  "s'  ,pref light  ,  completion) , 
airborne  < 'B-10'), 

Imtitiill  '•-10'  '•' «  W  's' , switch, position) , 
isnat*rial(  'B-10'  's' ,  'AM'  '•' ,  'generator'  '•'  , twitch, position) , 
lmatsrial(  'B-10' '»',  'AM'  's' .bleed,  'air'  , switch, position) , 

laanteriel ( ‘»-10  " •  •  >  'brakes ' 1 1  .check,  status) . 
iastatarlaM  •■-10' 'angina*  ,  running ,  status ) , 
isnatsrial ( ' »-10  " •  • , external ,  'power '  'a1, usage), 
lasuter  iai  ( ‘  >- 10 '  's',  axtamal,  'power 1  '•  ’ ,  switch, posit ion) , 
isnatsrial ( ' B-10 '  <•',  'iw  ‘ a ' , check, status ) , 
ianat axial ( '  S-10 '  's',  'throttles'  • position) , 
isnatsrial ( 'S-10'  's',  'trial'  's', cheek , status ) ) ) . 
ebjactlvasU,  (the, buffer] , 

[lauaaterleMthe,  'buffer '  '  a ' .presence) . 
die engaged (the, buffer) ] ) . 
ebjaetlvasU,  [tha, wind, sock] . 

[oheekedt  the.wlad,  sock)  ] ) . 
objectives (1, [captain, jack] , 

[‘claarad  to  dapaxt ' (captain, jack) , 
irsMtarlal (captain,  'lack'  's', taxi, clsarance) , 
lane  ter  1*1  (captain, • jack • • a • , takaof f , clearance) ] ) . 
objectives ( 1 , 'B-10‘, 

[iatMt  axial  ( 'B-10  •  ■«' ,  prat  light ,  ccssplat  ion) . 

Imeterlel  ( ‘B-10  "s'*  location) , 

inset  arial ( 'B-10 '  'a'*  'AM*  'a ', switch, position) , 
iaaaatariaK  'B-10*  's',  'AM*  'a'  *  ' generator '  's'  .switch, position) , 
lanaterial ( ‘B-10 '  ,  'AM'  >s '  ,blaad,  'air'  's'  .switch, position) . 

checked!  'B-10 "s'  .brakes) , 

lasattarial('B-10"s‘,  'engine'  's> .running. status) . 
isnatsrial  ( 'B-10 '  's', axtamal.  '  power '  's', usage), 
off  ( 'B-10*  's',  axtamal,  power), 
checked!  'B-10'  ‘S' .  'MIS' ) , 

hsatsxiall  'B-10'  's' ,  'throttles' ' '  .position) , 

Jsssatarial ( 'B-10 •  's',  'txiai'  's ‘  .check. status) )) . 
objective,! (1 ,  (the, buffer] . 

I ianatarial (the, 'buffer' 'a •  .presence) , 
disengaged (the. buffer)  ] ) . 
objective*, (1,  (tha. wind, sock) , 

(IwMtaxiel  (tha,  wind, '  sack  "s',  aback,  status) ) ) . 


/•  aid*,  elf  act  override  'S  n/ 
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TAB  6.  METUTOR  READY  FILE  FOR  PILOT  TRAINING 


. . . . . 

/*  Maaaa-Knda  Laaaca  Definition  til*  —  Runnabla  in  « Tutor  •/ 

. . 


<-  iyataic  typa_of_prolotj_f  ila/1. 


i-  multifile  type_of_prolog_file/l. 

i -  dynamic  lttm/1,  lHlonJaCre/1,  problan/l.  jirnM  —  _1ntrn  fl 

prcfel«Ltatia/},  atart_atate_t/3,  Soal_t/l,  reocanandad_t/4. 
preooodltloa^t/3,  4eletapoeteaaditioa_t/S, 
artrtpoo tooadltlon_t/i,  roiiokuH*.t/7,  ainguler_t/2. 
piurai_t/2,  ifply_tut_e/i.  tel<ti_tut_e/i, 


i-  multifile  Inhs/Ii  leeeon_latro/l,  problan/3.  probl«m_iatro/3, 

problaw_iVma  1  n / i ,  goal_t/3.  race— adod_t/4, 

prieeBiitiMLt/S,  delatepoetcoedition_t/5 , 
addpoet condi tioa_t/S,  rendchanga_t/7,  eingular_t /2 , 
plural_t/2 ,  «ppply_t*xt_t/a ,  atl«u.tut_t/4,  «M_tut_t/4. 


type_of_prolog_file( 'MXTutor  Laaaon  Plla ' ) . 


/“  leuaoo/1  •/ 
leaaeol  (pilot, training. 


/*  lHaoa.iatra/1  */ 

lo*eon_intro<  'Mmm  to  Pilot  Tr aiming,  Tart  2  Takaoff ' ) . 

lee aon_ intro ( * •) . 
leee«at_iat  ro ( •  . 

laaanm_intro( 1  Tba  purpoaa  of  tbia  laaaoa  ia  to  eoquaiat  you  with  tto'). 
l««WLlitto(  'bealc  prooedarea  in  taking  off  —  including  pra flight  check e,  •  > . 
laatom  titml  ‘tirrer  rn— >m1  n»T  1  rai  and  takaoff  prooeduraa  • )  . 

.1—  on_1nt«o(' ■). 

leeocA_i*troC  lkan  an  too  major  augment a  of  the  paroeaaa  —  thoaa  •). 
lataaajafnl  'pneaton  that  mat  ha  taa  at  tba  tmia*!  and  thoaa  that  ‘ ) . 
leaaoat_iat  ro  ( '  ara  dona  daring  tail  and  takaoff.  Aa  fir  at  too  problaaw ' ) . 
laaaco_  intro  ( '  will  train  yon  on  tha  too  part  a  >  tho  third  will  bring  it  all'). 
laaaon_intro(  ’together  for  yoo  far  a  oeoprahanalvo  taat . ' ) . 
laaaon_intro  ( 

laaaoauiatrol'  good  back,  captain! ' ) . 


/*  groblam/1  •/ 

problamU ,  ( ’Ptrat  * ,  ‘half  •  ] ,  (captain.  jack] ) . 
VNhbndil'aaMnd'i'lalf1).  t captain,  jack] ) . 
ItcbbnO.  ('Oenprahanaioa' ,  **001'],  (captain,  jack] ) . 


/•  problem,  intro/ 2  •/ 

pwMnLlntwU.  ■  gamin*  X  Prof  light  oparationa ' ) . 
p»nblam_  intro  ( 1 .  “I. 

problem,  intro ( 1 , •  Pirat,  oa  will  train  yon  on  tha  procedure  for  handling  tha' ) . 

pnblncttnll.  ‘aircraft  wham  yen  firat  arrive.  Tow  job  ia  to  etart  with  an*), 
problem,  in tro ( 1, 'aircraft  with  everything  turned  off  and  taka  it  through  the'). 
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preblait_intro(l,  'initial  aaquanc*  of  aback*  and  gain  cltnuci  to  depart  th* 1 ) . 
probleai_intro(l, 'terminal.  Oood  luek,  Captain i ' ) . 
problan^lntro  ( 1 ,  •  • ) . 

probla*_lntro (2 , 'Taxi  and  Takeoff  Procedures • ) . 
problem,  int  ro ( 2 , • ■ ) . 

probleu_intro(2,  •  in  this  problem,  your  plana  la  now  raady  to  laava  tha  terminal ' ) . 

problwa_i ntro(2 , 'and  towar  baa  grantad  you  panaiaaion  to  dapart.  Tour  job  ia  to'). 

preblaat_intro(3,  'taxi  tba  airoraft  to  tha  runway,  parfora  tha  Xaat  aat  of  ehaoka,  1 ). 

protolaa_intro(2, ‘and  fly  your  h-10  aircraft.  Don1 ‘t  forgat  to  ceonunieata  with  tha'). 

problaauintroO, 'towar.  Oood  luck,  captain!'). 

problem. intro ( 2 ,  "). 

probla*_iatf'J  ( 3 , '  Ceaprebenaive  Taat ' )  . 

problan_ intro ( 3 , • • ) . 

problaoL.intro(3,  •  Mow  that  you  hava  collated  both  phaaaa  of  tha  prooaaa,  '). 
problaa_intro(3, 'lat* 'a  put  tha  wbola  thing  togatbar.  Oood  luck!'). 


/•  problaa.domain/3  •/ 
problaat_dcaain  ( 1 ,  pilot , 
t [captain. jack] ) ) . 
probl<na_doBain  { 1 ,  aircraft , 

t'M-XO'l). 

problaat.doauLin(l,Uuf  far, 
t [tba, huff ar])) . 
problan_doaain<l,  [wind,  aoek] , 
( [tha, wind, aoek] ] ) . 
probXaat_do*ain(2  .pilot , 

[ [captain, jack] 1 ) . 
probl«at_ifcaaaln  (3,  aircraft. 
CP-101]). 

problaak_4oamln(  2,  buffer, 

[ [tha, huff ar] ] ) . 
problaat_doamin ( 2 ,  (wind, aoek], 
i (tha, wind, aoek] ] ) . 
prablaaudoaain  ( 3 ,  pilot , 

[ [captain,  jack]]) . 
problaat_de»ala  (3 ,  aircraft , 
CP-10'J). 

prnhl«ai.rtcami«(l,  buffer, 

( [the. buffer] ] ) . 
preblea*_de«nin  ( 3 ,  (wind,  aoek) . 
[ (tha, wind, aoek) ] ) . 


/•  ataic_atata_t/3  •/ 
atart_atata_t (X, 

I). 

[•at  tha  taminaX'  ( 'P-10' ) , 
off  CP-101  ••',  Wl, 
off  ( ’»-10 "a ' ,  'hPP  • ' a •  .generator) , 
off  Cl-10 "a1, 'AW' 'a '.bleed, air), 
unchecked ( *»-10 ' 'a', brake*), 
off  CP-10  "a*,  angina), 
available ( >a-10' 'a' .asternal, power) , 
off  ( aM-XO*  external , powe_- ) , 
unchecked  CP-10  "a1. 'MW'), 
off  CP-10  "a*,  throttle*), 
unchecked  CP-10  "a ‘.trim), 
preaant  (the, buffer) , 
diaangagad(tha, buffer) ) ) . 
atart _et  at a_t ( 3 , 
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u. 

( 'cleared  to  depart 1 (you) , 
checked!  '>>10'  , brehea) , 

off  CP-10'  .external,  power) , 
checked! 'B-10'  '  s  * » ‘ MWS 1 )  , 

'prof light  inspected ' ( 'B-10 • ) , 

'st  the  terminal'  ( 'B-10  1 ) , 
on(  'B-10'  's', 'ABU'), 

<n>(  'B-10'  's' ,  ' APO ‘  ' s  1 , generator ) , 
on(  'B-10 "s',  'ABC*  's', bleed, air) , 
running ( 'B-10‘ ‘s' , engine) , 
available ( ' B-10  "  a ' , external , power ) , 
off ('B-10* ‘s', throttles), 
unchecked ( 'B-10 “s', trial , 
die engaged (the, hut for) , 
present (the, buffer) } ) . 
st«urt_state_t  ( 3 , 

(1, 

('at  the  terminal' ('B-10'), 
off ( 'B-10' 's', 'ABO'), 
off ( 'B-10' ‘s', 'ABU' 'S', generator) , 
off ( 'B-10 ' 's', 'ABU' 's', bleed, air) , 
unchecked) 'B-10' 'e' , brakes) , 
off ( 'B-10' 's' .engine) , 
available ( 'B-10' 1  a ' .external, power) , 
off ( 'B-10* 's', external, power), 
unchecked ( 'B-10  "  s  • ,  'IMS ' )  . 
off  ( 'B-10  "s',  throttles) , 
unchecked ( • B-10 ' • a ' , trim) , 
present (the, buffer) , 
disengaged (the, buffer) ) } . 


/•  goal_t/3  •/ 
goal_t (1, 

I). 

( ‘cleared  to  depart ' (you) , 
checked! 'B-10' 's'. brakes), 
off ( 'B-10 ' ‘a ' . external, power ) , 
checked) 'B-10 "s 'WM'), 
disengaged  (the,  half  far)  ] ) . 
foal_t(2, 

U, 

I 'cleared  tor  takooff ' (yew) , 
airborne ( 'B-10 1 ) . 
disengaged  ( the,  taf far) , 
checked (the,  wind, sock) ] ) . 
goal_t(3, 

(1. 

(‘cleared  for  tekeof f ' (you) , 
airborne ( ‘B-10* ) . 
diiteagagedltke,  hotter) , 
cheeked 'the, wind, seek) ] ) . 


_t/«  V 

_t  (  (captain,  jack] , 

(aircraft, 
pilot] , 

t ‘preflight  lnspootod* (arg(l) ) ]. 
conduct (prof light, inspoctlon.oo,  argil) )) . 
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race— nJ»d_t  ( [captain,  jack) , 

(aircraft, 

pilot], 

(on  (para  (1) ,  axtarnal, power)  ] , 
angaga (parg (1)  ,axtarnal,powar) ) . 
roo—nda4_t  { (captain,  jack] , 

[huff ar, 
aircraft) , 

(angagad(argd) )  ] , 
aaaaga(aro(l) > ) • 

Mice— ado4_t  ( (captain,  jack] , 

(aircraft, 
huf far, 
pilot] , 

[running! parg (1)  .angina)  ] , 
•tart(pargd) .angina) ) . 
raccaaaandad_t  (  (captain,  jack] , 

[aircraft, 
pilot] , 

tonvparsr(i) ,  'kPO'l). 

•tart  (parg(l) ,  ‘APO* ) ) . 
raccamandadt ( (captain, jack] , 

[aircraft] , 

[on (parg (1) » ‘APD‘ *a ' .ganarator) ] , 
angaga (parg ( l ) , w 1  a ■ .ganarator) ) 
race— naia<_t  ( (captain,  jack] . 

(aircraft] , 

(on(pargd) . 'APO'  •■ ,blaad,air) ] , 
angaga  (parg  d) ,  'kPU'  'a',bl*ad,  air) ) 
raccanandad_t ( [captain, jack] , 

[huffar, 
aircraft 1 , 

[dlaangagad ( arg (1) ) ] , 
di*ang*ga(arg(l) ) ) . 
race— rtact.t  (  (captain,  jack] , 

(aircraft, 

tanffar, 

pilot), 

(off  (parg  d) .  aitanul ,  powar )  ] , 
livangaga (parg  (1) , aztaroal.powar) ) . 
racoanandad_t ( (captain, Jack] . 

(aircraft, 
pilot, 
huff or] , 

(ckackad  (parg  (1 ) ,  *  IMS  •  H , 
clack  (parg  (1) ,  '—»■)>. 
ran-— ->ndad_t  ( [captain,  Jack] , 

(aircraft, 

pilot], 

(chaokoA(parp(l) .fcrakaa) ] , 
aback (parg  (1) .brakoa) ) . 
rooe— 4a4_t(  [captain,  jack) , 

(pilot, 

aircraft), 

Cclnarad  to  dopart  •  (arg(l)  ]  3 , 
rognaat (flight , oloaranco) ) . 
rooaa— da<jfc  <  (captain.  Jack] , 

(pilot, 
aircraft] , 

t'altxirod  for  taki'  targ(i))], 
rogaaat (ttnl.olaaranoo) ) . 


f  cr— ■nii«d_t  ( [captain,  jack] , 

[ aircraft , 
pilot), 

t 'on  the  rumray'  (argil))), 
taxi(argd) ) ) . 

raooMaanda4_t ( (captain, jack) , 

[pilot, 
aircraft] , 

[ ' cleared  for  takaoff ’ (arg(l) ) ) , 
request (takeoff ,olaaranea) ) . 
raccaaeandad^t  (  [captain,  jack] , 

( [wind,  aock] , 
pilot, 
aircraft] , 

( checked!  argd) ) ) , 

check (%rg(l) ) )  • 
race— aadad-t  ( [captain,  jack] , 

[aircraft, 

pilot, 

(wind, aock] ] , 

[cheeked  (pargd) ,  trim)  ] , 
adjuat(pargll) , trim) ) . 
racoa»ended_t  ( (captain,  jack] , 

[aircraft, 

pilot], 

(off  (pargd) ,  'APV )  ] , 
shut (off ,parg(l) , 'kPU' ) ) . 
recoea&anded.t  ( [oaptaln,  jack] , 

(aircraft, 

pilot), 

[full (parg(l) .throttles) ] , 
aax(pargd)  .throttles) ) . 
reaonasnded_t ( [captain, jack] , 

[aircraft, 

pilot), 

[airborne  (argd) )] , 
fly  (the, argil) ) ) . 
reon— wde iV_t  ( [captain,  jaak] , 

(aircraft), 

(oft (pargd) ,  'Mg*  's'  .generator)  ] , 
disengage  (pargd) ,  'A»V  's',  generator) ) 
renew endsd-t  ( [captain,  jack] , 

[aircraft] , 

[off  (pargd),  'k»0'  's' .bleed,  air)  ] , 
disengage (parg(  1) ,  'MV  ‘s', bleed, air)) 
reeaanemda4_t ( [captain, jack] , 

(aircraft), 

[oft  (pargd) , angina)  ] . 
shut  (oft, pargd)  .engine) ) . 
renc— ina«d_t  ( (captain.  Jack) , 

(aircraft) , 

(oft  (pargd)  .throttles] ) , 
out  (pargd), throttles)) . 

T»»i—ead«<l_t  ( (captain.  Jack] , 

[aircraft], 

[checked (parg d)  .trin)  ] , 
check  (pargd)  .trim) ) . 


/•  precondition^ /S  */ 
pceoondl t ion^t  (  (captain,  jack] 
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t  [wind, aosk] , 
pilot, 
aircraft) , 
ohaek(argd) ) , 
t). 

['em  tha  runway' (arg (3) ) ] ) . 
precondition^ ( [coptcin, jack] , 
[buffer, 
aircraft) , 
dieengage{arg(l) ) , 
t), 

(ontpargd) ,  'AW' ' a '  ,bloed, air) , 
angaged(argd) ) , 
praaant(argd)))) . 
prooondi t ion_t ( (captain,  jack) , 
[kuffar, 
aircraft] , 
angagetaxgd) ) , 

0. 

(on<parg(2) , asternal, powor) , 
disengaged  (argd) ) , 
present  (argd) ) , 

‘prof light  lnapoctad'  (argd) )  ] ) . 
precondition^ ( [captain, jack] , 
(aircraft, 
pilot] , 
taxi(argd) ) , 

(]. 

[‘cloarod  for  taxi'  (argd) ) , 
not  ( 'on  tha  runway '  (argd) ))]) , 
precondition^  ( [captain,  jack] , 
(aircraft, 
pilot, 

(wind,  aockl  ] , 
adjuat  (pargd)  ,tri») , 

(1. 

(ohaekod(argO) ) , 
unchackad (pargd) ,  trim)  ] ) . 
preooadit ion_t ( [captain, jack] , 
[aircraft, 
pilot, 
hutfar] , 

ohaek(pargd).  ‘Ml*'), 

t). 

(off  (pargd)  .external, power) , 
unchackad  (pargd) ,  'Ml' )  ] ) . 
preooadit ioa_t ( (captain, jack] , 
[aircraft, 
pilot), 

check  (pargd)  .brakaa) , 

I). 

[chock  ad  (pargd) ,  •MWa1}, 
unchackad  (pargd) , brakaa)  ] ) . 
preocndlt lca_t  ( (captain,  j  aek) , 
(aircraft] , 
check  (pargd)  .trim) , 

(). 

(unchackad  (parg (1) , trim) ) ) . 
pr  a  oend ltica_t ( (captain, jack] , 
(aircraft] , 

cut  (pargd)  ,throttlaa) , 
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(]. 

(set (off (parg ( 1) , throttles ) )  ] ) . 
preconditions ( [captain, jack] , 

WMTtfti 
pilot) . 

fly(tha,arg(l) ) , 

tl. 

(full (pax? (1) .throttle*) . 
not (airborne (arg(l) ) ) ] ) . 
pracondit ioo_t ( (captain, jack] < 

(aircraft, 
pilot) , 

aax(pavg(l)  .throttle*) , 

(], 

(off  (parg(l), 'APO'), 
not (Cull (parg(l) .throttle* ) ) , 

1 claarad  fox  takeoff ’ (arg(2) ) 1 ) . 
preconditions ( (captain, jack] , 

[pilot , 
aircraft] , 

requeet  ( f  light ,  clear anca ) , 

(1, 

(on(parg(2) ,  'APU‘  ‘s'  .bleed, air)  ] )  . 
preconditions  ( [captain,  j  ack] , 

[pilot, 

aircraft], 

request (takeoff , clearance) , 

0, 

['on  the  runway' (erg (3) ) , 

■cleared  for  taxi' (arg(l) ) ] ] . 
preconditions  ( (captain,  j  ack] , 

[pilot, 
aircraft] , 

request (taxi. clearance) , 

(). 

(‘cleared  to  depart' (arg(l)), 
checked (parg ( 2 ), brakes )]) ■ 
preconditions  ( [captain,  jack] , 

(aircraft, 
pilot] , 

start (parg (1), 'ATP'! , 

(1. 

[running (parg (1) .engine) . 
off  (parg(l).'APU'). 

'preflight  inspected* (arg(l) )]) • 
preconditions  ( (captain,  jack] , 

(aircraft, 

buffer, 

pilot). 

start (parg ( X ), engine ) , 

(), 

(eagaged(er?(2>), 
off  (pnrg  (i).  engine), 

'preflight  Inspected' (erg(l)))). 
preconditions!  [captain,  jack] , 

(aircraft), 

disengage  (parg (1) , 'APO' 'a' .generator) 

(). 

(ontparg (1) ,  'AH' ) , 
on (parg (1), 'APO' 's' .generator) ] ) 
preconditions  <  (captain,  jack) . 


[aircraft , 

huffar, 
pilot] , 

diaangago (pars ( X ) » axtarnal , powar ) , 

tl. 

(diaangagad ( arg (2 ) ) , 
cn  (pared)  ,  axtarnal, powar)  ] ) . 
praeondi t ioa^t ( [captain, Jack] , 
t aircraft], 

angaea  (pared) ,  'AM' ' a ‘ , ganarator ) , 

tl. 

(on(pergd) ,  'AYS' ) , 
off  (pared) ,  'APO'  'a '.generator) )) . 
praeondi t ion^t ( [captain, jack] , 

[aircraft, 
pilot] , 

engage (pare (1) , external, power ) , 

[], 

( ‘prof light  lnapeated'  taxed) ) , 
off  tpargd)  .external, power) ) ) . 
preconditions ( [captain, jack] , 

(aircraft, 
pilot) , 

ahut  (off  .pargd) ,  'APC  ), 

(]. 

(ehaokad (pared)  .trim) , 

'cleared  for  takaoff 1 (arg(2) ) , 
on  (pared) ,  'APB' )  ] ) . 
preconditions ( [captain, jack) , 

(aircraft), 

abut  (off. pared)  .angina) , 

(), 

[  running  (pared)  .angina)  ] ) . 
precondition,  t ( (captain. jack] , 

(aircraft, 
pilot] . 

conduct  (prof  light ,  inapaot  ion,  on,  arg  d )) , 

(). 

Cat  tha  terminal '  (arg(l) ) ) ) . 
pracoodit ion_t ( [captain, jack! , 

(aircraft) , 

diaaagaga (pared) ,  'APB'  .blaad.air) , 

(). 

(cn(parg(l),  'APB'  .ganarator) , 
on(pargd),  W  ‘a* .hlaad.air) ) ) , 
pracondition_t  ( [captain,  jack] , 

(aircraft) , 

—gaga (parg(l),  'APB'  ‘a1  .hlaad.air) , 

(1. 

[on (pared) ,  'APB'  *a <  .ganarator) , 
off  (pared),  'AW  '•'.hlaad.air)]) . 


/•  4alat— ootoanditioA_t/S  •/ 
Aeletapoet  conditions ( (captain. jack) , 
((vind.acck) , 
pilot, 
aircraft), 
oAeoMergd) ) , 

(1, 

(]). 
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deletepo«tooadition_t ( [captain, jack] 
[huffar, 
aircraft], 
dieaogaga ( arg ( 1 ) ) , 

n, 

tsngaged(argU))]) . 
dalatapoateoadition_t t (captain. Jack] 
[huffar, 
aircraft) , 
engage  (argd) ) , 

[), 

(disengaged  (argd) )  ] ) . 
dalatapoat condl ticm_t  [  [captain,  jack] 
[aircraft, 
pilot], 
taxi(argd) ) , 

!). 

[‘at  tha  taraiaal1  (argd)), 
airborne ( arg (1 ))] ) . 
deletapoateonditioa_t ( [captain, jack] 
[aircraft, 
pilot • 

(wind,  aoekl  ] , 
adjuat (parg (1) , trim) , 

I). 

[unchecked  (parg  ( 1 ) , trim) ] ) . 
dalatapoitoondition_t ( [captain, jack] 
[aircraft, 
pilot, 
huffar] , 

check  (parg  d).  'MM'), 

(1. 

[  unchecked  (parg  (1) .  ‘Ml  • )  ] ) . 
deletepoat condi t ion_t i (captain, jack] 
[aircraft, 
pilot], 

check (parg(l)  .brakaa) , 

(). 

[unchecked (parg  (1) .  brakaa) ] > , 
deletapoeteenditien_t ( [captain, jack] 
(aircraft] , 
check (perg(l)  ,trln) , 

(1. 

[unchecked (parg  d) ,  trip)  ] ) . 
deletapoetcoaditlon_t ( [captain, jack] 
[aircraft] . 

cut  (parg  d) .  throttles ) , 

0. 

[idle  (pared)  .throttles) , 
full  (pargd)  .throttles) ; ) . 
daletapoateoadltlcn_t ( (captain, jack] 
(aircraft. 

Pilot], 

fly  (tha,  argd) ) , 

(). 

(‘at  tha  temiaal ‘  (argd) ) , 

•ca  tha  nMNy‘(arg(l)))). 
deist apoet  eoodlt ica_t  ( (captain, jack] 
(aircraft, 

Pilot), 

■ox  (pargd),  throttles). 


I). 

[off (parg(l) .throtvias) , 
idlalpargd)  , throttlae)  ] ) . 
dalatapoat  conditions ( [captain, jack] , 
(pilot, 
aircraft] , 

rcquaat (flight , glauuct) , 

(]. 

tl>. 

dclatapoatcoaditions  ( (captain,  jack) , 
(pilot, 
aircraft] . 

request (takaof  f  , clearance) , 

tl. 

tl). 

dslatepostooadltior  t  <  [captain,  jack], 
(pilot, 
aircraft] . 

rcqu«st(taxi,alaaranea) , 

(], 

(J). 

dalstspost.oonditions ( [captain, jack] , 
[aircratt, 
pilot], 

start (parg(l> , 'hru' ) , 

u, 

(off  (parg(l),  w)]) . 
dclatspostconditions ( [captain, jack] , 
(aircraft, 
huff or. 

Pilot], 

otart(pargd)  .angina) , 

(]. 

(off (parg(l) .meins) ] ) . 
dsletapoat  conditions  ( (captain,  jack] , 
[aircraft] , 

dlaaagaga (parg(l) , ‘kru’ 's' .gcnsrator) , 

(1. 

(oo(parg(l),  'kfO'  's'.gaaoratori])  • 
dolstapostocedlticas  ( [captain, Jack] , 
(aircraft, 
buffer, 
pilot], 

<Usaagaga(paxg(l) ,  external , power ) , 

(]. 

(co(paxgd)  , external, pocar)  ] ) . 
daictapoctoonAiticnS  t  (captain,  jack] , 
[aircraft], 

aagaga (parti li. W 'a'.pmtratoz) , 

(1. 

(off  (par* (1),  'WO'  ’a'.tmorator)]). 
dslart  apoctoondit  ica_t  ( [captain,  jack]  . 
(aircratt , 

Pilot  1. 

aa*o*o  (part  (1) .  oxtaml,  power  > , 

(1. 

[off  (par*(l)  .ortaraal.pcwar)  1 ) . 
Aolct^octocndltlonS ( [captain,  jack] , 
(aircraft, 

!»U*t], 

shat  (eft  .pargd, ,  W), 


181 


t). 

taa(pargd) ,  'HW'|  J) . 
delatapostcoadltlon_t  ( [captain,  j ack] , 
[aircraft] , 

ataut(off,paxgd)  .angina) , 

(1. 

[running (pa?g(i) .«ngia«) ) ) . 
dalatapoatoon£itionwt ( [captain, jack] , 
(aircraft, 
pilot], 

conduct (prat light, inapact ion, on, arg(l) ) , 

(]. 

(]). 

daletapoat  condition^  ( [captain,  jack] , 
[aircraft], 

diaangaga (parg(l) ,  'APO> ••' , blood, air) , 

(]. 

(em(pargtl) ,  'APO'  '• 1  ,blaad,air)  J ) . 
daxatapoat condit ion_t ( [captain,  jack 1 , 
[aircraft] , 

angaga (pnrg d ) ,  W  *a*  ,blaad,air) . 

(], 

[off  (pared) ,  ‘MU'  'a1, bleed, air) ] ) . 


/•  addpoateondition_t/5  */ 
addpost condi tion_t ( [captain, jack] , 
( [wind, aock] , 
pilot, 
aircraft] , 
chack(argd) ) , 

n. 

(ctaackad(argd) )  1 ) . 
oddpoatocnditlon„t ( (captain, jack] , 
(tanffar, 
aircraft] , 
diaeagaga  (argd)  J , 
t). 

[dl*eiu>aged(arg(l) )]). 
addpejtccaditlcn_t  ( [captain,  jack] , 
[tanffar, 
aircraft), 

•agaga(argd) ) , 

(1. 

[ engaged (argil) > ) ) . 
•Mpoatcanditlan_t  (  (captain,  jack) , 
(aircraft. 

Pilot], 

taxi(argd)). 

(1. 

('em  ttaa  runway •  (argd) )]) . 
adflt  oatocaditlon_t  (  (captain,  jack] , 
[aircraft, 
pilot, 

[wind,  nook)  ] , 
adjnat(pargd)  ,trin) , 

II, 

[ataackal (part (1), trip] )<• 
aW>»Mcal1  tlea_t  ( [captain,  jack] , 
(aircraft, 
pilot, 
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huf Car) , 

oluoklpusU),  '«W'), 

C). 

[ehaokad  (pars  ( 1) ,  WW‘11) . 
addpoatcoaditionS ( (captain, jack] . 

C aircraft, 
pilot) , 

chaok (parg ( 1 ) ,bxakaa) , 

I), 

(ehaekad(ptrgU)  .brakaa) ) )  > 
aidpoatcoudit ionS ( [oaptala, jack] , 
[aircraft 1 , 
cheek  (parg(l)  .trial , 

(), 

(ohaakad(parg(l) .trim)  1 ) . 
nddpoatcondltionS ( [captain , jack] , 
[aircraft 3 , 

cut (parg <  l) , throttlaa) , 

[), 

[off  (paxg(l) , throttlaa) ) ) . 
addpoatcondltloa>.t(  [captain,  jack] , 
[aircraft, 
pilot) . 

fly(tha.argtl) ) , 

(]. 

[airborne  (arg  ( 1 ) ) ) ) . 
addpoat  conditions  ( [captain,  jack) . 
[aircraft, 
pilot] , 

aar (paxg(l) .throttlaa) , 

(). 

(full (parg ( l ) , throttlaa ) ! I . 
»ddpo»t  conditions  ( Icaptain,  jack] , 
[pilot, 
aircraft] , 

request (flight, clearance) , 

[]. 

['clsarad  to  dapart ■ (argil) ) ] ) , 
addpoatoondltions  ( [captain,  jack] , 

(pilot, 
aircraft] . 

requaat (takaof f .clearance) , 

(), 

( ■ cloarod  for  takeoff ' (arg (1) ) )} , 
addpoatconditionS ( [captain, jack) , 
(pilot, 
aircraft) , 

requaat (taxi, olaaraaca) , 

(]. 

[‘cloarod  for  taxi* (arg(l) ) )) • 
addpoatoooditlea_t ( (captain, jack] , 
(aircraft, 
pilot), 

start  (paxg(l),  W ) , 

t). 

[ on  (parg (l),  'hPO')]) . 
addpoatooodltiooS ( (oaptala.  jack] , 
(aircraft, 
baftsr, 
pilot) 

start  (pargt- 1  .angina) , 
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Cl. 

[running (parg (1)  .angina)  ] ) . 
nddpo  at  condition^ ( [captain, jack] , 

[aircraft] , 

diaangaga (parg  1 1 ) , 'APO ' ganarator ) , 

[]. 

[off (parg (1) , 'APU 1 'a' , ganarator) ] ) . 
addpoa t condi tlon_t ( [captain, jack] , 

[aircraft, 
huffar, 
pilot] , 

diaangaga (parg(l) ,aztarnal,pawar) , 

[], 

[off  (parg(l)  ,aztarnal,powar)  ] ) . 
addpoateonditieA_t ( [captain, j  ack] , 

[aircraft] , 

angaga (parg (1) ,  'APU'  'a •  .ganarator) , 

(], 

(on(pargU),  'APU1  'a1, ganarator)]) . 
addpoatcondition_t ( [captain, jack] , 

[aircraft, 
pilot] , 

angaga (parg(l) ,aztarnal,powar) , 

[], 

[on(pargd)  ,aztarnal,powar)  ] ) . 
addpoatcondition_t ( [captain, jack] , 

[aircraft, 

pilot], 

ahuttoff ,parg(l) , 'APO' ) , 

[], 

[off (parg(l) , 'APU' ) ] ) . 
addpoatcondition^t ( [captain, jack] , 

[aircraft] , 

abut (off ,parg (1) , angina) , 

[], 

[off (parg(l) .angina) ] ) . 
addpoatcondition_t ( (captain, jack] , 

[aircraft, 
pilot] , 

conduct (praf light, inapaction.on, arg ( 1) ) , 

[], 

[ 'praflight  inapactad' (arg(l) ) ] ) . 
addpoatcondition_t ( [captain, jack] , 

[aircraft] , 

diaangaga (parg ( 1) , 'APD' 'a* ,blaad,air) , 

[], 

[off (parg(l), 'APU1 *a ■ ,blaad,air) ) ) . 
addpoatcondition_t ( [captain, jack] , 

[aircraft] , 

angaga (parg (1) , 'APO1 ' a ' ,blaad, air) , 

(1, 

ton (parg (1) , 'APO' 'a' ,blaad,air) ] ) . 


/*  randchanga_t/7  */ 


/*  aingular_t/2  •/ 


/*  plural_t/2  */ 
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/*  *pply_t«xt_t/4  •/ 
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APPENDIX  E.  SCRIPT  RUN  OF  METUTOR  ON  AN  MEBUILDER 

FILE 


This  appendix  shows  METutor  being  run  on  the  lesson  produced  in  Appendix  C  and 
provided  in  Appendix  D,  called  “pilot  training  I”. 


script  started  on  Wad  JUl  27  14:11:36  1994 
.alias:  No  such  fils  or  directory. 

>  -galvint/mebuild/KBTutor 

Name  the  lesson  £ile>  pilot_training_I 

+ - - - + 

I  Means -Ends  Tutoring  System  --  Version  29  (METutor)  | 

+ - - - - — - - — + 

I  by  Professor  Rowe  and  CPT  Galvin,  Naval  PO  School  I 


Welcome.  The  name  of  this  lesson  is  "pilot  training  I". 

PILOT  TRAINING :  LESSON  1 

This  lesson  is  the  first  lesson  in  flying  an  aircraft.  After  this 
lesson  you  will  be  familiar  with  the  process  of  starting  the  plane  and 
talcing  off.  The  specific  skills  taught  in  this  lesson  are: 

(a)  Conducting  all  preflight  checks  and  inspections 

(b)  Basic  conmunications  with  the  tower 

There  is  one  problem  in  the  lesson,  a  comprehensive  test  of  tba 
skill.  Good  luck. 


There  are  3  problems  in  the  lesson. 

You  may  "list"  the  problems,  "view"  a  suamary  of  a  problem, 
or  "do"  a  problem,  "help"  is  also  available. 

MBTutor>  help 

The  following  commands  are  available  at  this  level: 
help  —  print  this  text 

quit  —  quit  METutor 

list  --  lists  all  the  problems  available, 

learn  --  <not  yet  implemented  —  this  is  a  hook 

for  future  use  in  administering  lessons. > 
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vi»*  [problem  -(number >] 

—  print*  a  description  of  the  problem, 
do  [problem  <number>] 

—  run  a  problem. 

Xf  the  optional  argument  i*  not  supplied,  JOE  Tutor  will  ask 
for  it.  X  different  coomand  set  is  available  while  running 
a  problem. 


MBTutor>  view  problem  3 

The  nemo  of  the  problem  is  "Comprehensive  Test". 

Descriptions 

How  that  you  have  successfully  completed  the  various  phases  of  the 
procoss,  let's  put  the  whole  thing  together  from  the  start.  Good 
luck  l 


MKTutor>  do  problem  3 

Loading  and  checking  the  problem . please  wait. .. .Done. 

The  following  is  thi  current  situations 


Now  that  you  have  successfully  completed  the  various  phases  of  the 
process,  let's  put  the  whole  thing  together  from  the  start.  Good 
lucki 


The  following  are  your  objectives  s 

you  must  be  cleared  to  depart,  you  must  be  cleared  for  taxi,  you  must 

be 

cleared  for  takeoff,  B-10  must  be  preflight  inspected,  the 
aircraft  must  be  airborne,  B-10's  brakes  must  be  checked,  the 
aircraft's  engine  must  be  running,  B-10's  NWS  must  be 
checked,  B-10' a  throttles  must  be  full,  B-10's  trim 
must  be  checked,  the  buffer  must  be  present,  and  the  wind  sock 
must  be  checked 

The  following  is  the  current  situation! 

B-10  is  at  the  terminal,  the  buffer  is  disengaged,  the  buffer  is 
present,  B-10's  APU  is  off,  B-10's  engine  is  off, 

B-10 ' s  throttles  are  off,  B-10's  NWS  is  unchecked, 

B-10's  brakes  are  unchecked,  B-10's  trim  is 
unchecked,  B-10's  external  power  is  available,  B-10's 
APO's  genarator  is  off,  B-10's  external  power  is  off,  and 
B-10's  AFU's  bleed  air  is  off 

What  do  you  want  to  do?  help 


You  stay  enter  an  operator  or  one  of  these  special  comnandst 
help  —  print  this  text 

quit  --  return  to  HBTutor  main  level 

view  state  --  pretty  prints  the  current  state 
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view  objectives  —  pretty  print*  your  objective* 
query  operator  <operator> 

--  print*  all  information  about  an  operator, 
query  object  <object> 

--  print*  operator*  available  on  an  object, 
query  fact  <object> 

—  print*  all  information  about  a  fact  or  objective. 
The  following  are  the  operator*  available  in  this  lesson * 

11]  adjust  B-10's  trim 

12]  check  B-10's  SWS 

13]  check  B-10' s  brake* 

14]  check  the  wind  sock 

15]  conduct  preflight  inspection  on  B-10 

16]  disengage  B-10's  external  power 
[7]  disengage  the  buffer 

18]  engage  B-101*  APU's  bleed  air 

19]  engage  B-10's  XPU's  generator 

[10]  engage  B-10'*  external  power 

[11]  engage  the  huffer 

[12]  fly  the  B-10 

[13]  max  8-10'*  throttle* 

[14]  request  flight  clearance 

[15]  request  takeoff  clearance 

[16]  request  taxi  clearance 

[17]  shut  off  B-10 ' s  APU 

[18]  start  B-10's  APU 

[19]  start  B-10 's  engine 

[20]  taxi  B-10 


What  do  you  want  to  do?  view  operator  start  B-10's  APU 
Sorry,  that  is  not  a  valid  command.  Please  try  again. 

What  do  you  want  to  do?  query  operator  start  B-10's  APU 

The  following  is  true  about  "start  B-10's  APU" j 

**  The  operator  is  recommended  for  achieving  "B-10's  APU  is  on  " 

•*  The  precondition  for  the  operator  is  "B-10's  engine  must  be 
running,  B-10's  APU  must  be  off,  and  B-10  must  be 
preflight  inspected  ”. 

•*  The  postcondition  for  the  operator  is  "B-10's  APU  is  no  longer  off 
"  while  "B-10 '  s  APU  would  be  on  ". 

What  do  you  want  to  do?  query  fact  B-10's  external  power  is  on 

The  following  operators  are  recommended  for  achieving  this  facts 
[1]  engage  B-10's  external  power 

What  do  you  want  to  do?  query  object  B-10 

The  following  can  be  performed  on  "B-10". 

**  Operator  ■  "conduct  preflight  Inspection  on  B-10" j 
The  operator  is  intended  to  achieve  "B-10  would  be 
preflight  inspected  " . 
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**  Operator  ■  "taxi  B-10"t 

The  operator  la  intended  to  achieve  "B-10  would  be  os  the  runway  " . 
**  Operator  ■  "fly  the  B-10"i 

The  operator  la  intended  to  achieve  "B-10  would  be  airborne  " . 

What  do  you  want  to  do?  conduct  preflight  inspection  on  B-10 
You  chose  to  conduct  preflight  inspection  on  B-10. 

OX. 

[1]  B-10  is  now  preflight  inspected 

What  do  you  want  to  do?  start  B-10 'a  AFU 
You  chose  to  start  B-10' a  AFU. 

Have  you  confused  "B-10 'a  engine  is  running  "  with  "B-101 a 
engine  is  ofi  "? 

That  action  requires  thati 

II]  B-10 ' s  engine  must  be  running 

What  do  you  want  to  do?  start  B-10's  engine 
You  chose  to  start  B-10's  engine. 

Have  you  confused  "the  buffer  is  engaged  •  *  with  "the  buffer  is 
disengaged  ”? 

That  action  requires  thati 

11}  the  huffer  must  be  engaged 

What  do  you  want  to  do?  engage  the  huffer 
You  chose  to  engage  the  huffer. 

Have  you  confused  "B-10's  external  power  is  on  "  with  "B-10's 
external  power  is  available  "? 

That  action  requires  that; 

II]  B-10's  external  power  must  be  on 

What  do  you  want  to  do?  engage  B-10's  external  power 
You  chose  to  engage  B-10's  external  power. 

OK. 

II]  B-10 1 s  external  power  is  now  on 

What  do  you  want  to  do?  engage  the  buffer 
You  chose  to  engage  the  huffer. 

OK. 

II]  the  huffer  is  now  engaged 

What  do  you  want  to  do?  start  B-10's  engine 
You  chose  to  start  B-10's  engine. 
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OK. 

[X]  B-10'a  angina  ia  nov  running 

What  do  you  want  to  dot  raquaat  flight  olaaranoa 
You  ehoaa  to  raquaat  flight  olaaranoa. 

Hava  you  oonfuaad  "1-10* a  AMT  a  blaad  air  ia  on  -  with  "B-10'a  APU'a 
blaad  air  ia  off  ■? 

That  notion  raguiraa  thatt 

(1]  B-10'a  APU'a  blaad  air  nuat  ba  on 

What  do  you  want  to  do?  quary  faet  B-10'a  APU'a  blaad  air  ia  on 

following  oparatora  ara  racoanandad  for  aehiaving  thia  faett 
[1]  angaga  B-10'a  AN'a  blaad  air 

What  do  you  want  to  do?  angaga  B-10'a  APU'9  blaad  air 
You  ehoaa  to  angaga  B-10'a  APU'a  blaad  air. 

Hava  you  oonfuaad  "B-10'a  APU'a  ganarator  ia  on  “  with  "B-10'a  APU'a 
ganarator  ia  off  "? 

That  action  raquiraa  thatt 

[1]  B-10'a  APU'a  ganarator  otuat  ba  on 

What  do  you  want  to  do?  quit 
MBTutor>  quit 

>  axit 

>  axit 

acript  dona  on  Wad  Jul  27  14 < 15 i 26  1994 
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APPENDIX  F.  EXPERIMENT  CONDUCTED  USING  MEBUILDER 

This  Appendix  contains  the  raw  information  produced  and  gathered  in  the  process  of  conducting  the 
validity  experiments  during  the  Summer  Quarter  of  1994.  This  experiment  is  discussed  in  thorough  detail  in 
Chapter  V.  The  following  lists  the  information  in  this  Appendix. 

Tab  1.  General  Instructions  for  the  Experiment 
Tab  2.  Suite  One:  The  Scuba  Diving  Problem 
Tab  3.  Suite  Two:  The  Cooling  System  Problem 
Tab  4.  Sample  Run  of  the  Data  Collection  Program 
Tab  3.  Initial  Data  Files  for  the  Scuba  Diving  Problem 
Tab  6.  Initial  Data  Files  for  the  Cooling  System  Problem 
Tab  7.  Data  Collected 

Tab  8.  Selected  Comments  from  Participants 


c 
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TAB  1.  GENERAL  INSTRUCTIONS  FOR  THE  EXPERIMENT 


ASSIGNMENT 

You  will  be  required  to  construct  a  lesson  in  a  simple  procedural  task  using  two  different  tools.  One 
tool  is  based  on  the  principles  of  Computer-Aided  Instruction  (CAI),  the  other  using  a  intelligent  lesson 
authoring  system  (MEBuilder). 

PURPOSE  OF  THE  EXPERIMENT 

The  purpose  of  the  experiment  is  to  gather  evidence  concerning  how  well  MEBuilder  helps  teachers 
write  lessons  versus  older  methods.  This  evidence  will  be  interpreted  based  on  raw  data  produced  from  the 
following: 


a.  Amount  of  time  required  to  produce  the  lesson  material  in  each  platform.  This  will  be  measured  in 
terms  of  raw  time  and  number  of  steps  required. 

b.  The  completeness  of  each  lesson  -  whether  or  not  MEBuilder  hindered  the  writing  process  to  the 
point  that  the  desired  lesson  could  not  be  written  satisfactorily. 

c.  The  robustness  of  each  lesson  -  whether  or  not  the  resulting  lesson  affords  the  student  the  maximum 
mr  correct  numbers  of  choices  at  any  point  while  running  the  lesson. 

CONDUCT  OF  THE  EXPERIMENT 

The  experiment  will  be  conducted  as  follows: 

a.  Orientation.  JTiis  document  will  be  presented  and  classroom  instruction  given  on  the  differences 
between  CAI  and  ICAi  techniques.  This  will  be  followed  by  a  detailed  block  of  instruction  on  the  use  of  two 
tools  -  CAIBuilder  and  MEBuilder  -  introduced  later  in  the  text 

b.  Conduct.  A  set  amount  of  time  will  be  allowed  for  students  to  build  the  lesson  material  and  to  gather 
the  necessary  data  as  requested  below.  Handed  oul  separately  is  the  specific  subject  matter  the  student  will 
be  required  to  author  a  lesson  on. 

You  will  be  given  a  library  with  half-completed  solutions  in  it.  The  files  include  a  CAl-solution  where 
there  is  exactly  one  path  to  the  goal  and  no  options  given  to  the  student,  and  an  MEBuilder-solution  where 
there  is  exactly  one  path  to  the  goal  and  no  options  given  to  the  student.  Your  job  is  to  make  both  lessons 
robust  in  order  to  conform  more  closely  to  the  task  descriptions  given. 

NOTE:  This  experiment  is  intended  to  require  no  more  than  six  hours  of  application  running  time.  This 
time  includes  familiarization  with  the  two  systems.  If  you  are  having  serious  problems  performing  the 
requirements  under  six  hours,  contact  galvint  by  email  as  soon  as  possible  for  assistance. 

c.  Debriefing.  A  forum  will  be  held  for  students  to  provide  specific  general  comments  about  the 
experiment  In  addition,  the  experimentor  will  provide  additional  data  relating  the  students'  experiences  with 
the  expected  or  optimistic  results. 

TOOLS  AND  DOCUMENTATION  PROVIDED 

a.  General  Information,  Each  student  will  have  a  copy  of  this  document  plus  a  copy  of  the  specific 
subject  matter  for  his  lessons.  You  must  establish  a  single  subdirectory  for  this  project,  and  you  must  run  all 
the  below  listed  programs  from  within  this  subdirectory.  You  are  free  to  copy  the  executables  into  your  own 
directory  (it  totals  to  about  3.6MB). 

b.  C !  AITutor  and  CAIBuilder  tools.  Each  student  will  have  a  copy  of  the  user's  manual  for  the  C  AITutor 
and  CAIBuilder  systems.  The  programs  are  available  in  executable  form  in  -galvint/caitutor  and  are  called 
C AITutor  and  CAIBuilder,  respectively. 


194 


c.  METutor  and  MEBuilder.  Likewise,  the  student's  will  have  a  copy  of  the  user's  manual  for  METutor 
and  MEBuilder  systems.  The  programs  are  available  in  executable  form  in  -galvint/mebulld  and  are  called 
METutor  and  MEBuilder,  respectively. 

d.  Statistical  Gathering  Programs.  The  student's  will  have  access  to  get_data  which  is  a  simple  five- 
step  program  that  retrieves  statistical  information  from  the  student's  directory,  queries  some  time  information 
of  the  student,  and  then  prints  a  standard  data  report  for  analysis,  get  data  is  located  in  the  -galvint' 
mebuild  directory. 

e.  User's  Manuals.  User's  Manuals  for  CAlBuilder  and  MEBuilder  will  be  available  in  binders  in  the 
AI  lab  (they  may  be  available  individually).  The  user's  manuals  contain  a  description  of  the  programs, 
complete  command  references,  and  sample  sessions  using  a  lesson  with  a  scope  similar  to  that  of  the  assigned 
lesson. 

f.  Library.  In  the  -gal  vint/sample/lib/  directory  is  all  of  the  preliminary  data  you  will  need.  It  contains 
the  skeletal  lessons  for  both  die  C  AI  solution  (*  .cai)  and  the  MEBuilder  solution.  You  are  to  do  the  following: 

(1)  Copy  the  directory  into  an  lib  subdirectory.  It  must  be  named  lib,  so  if  you  are  -student  and 
you  intend  to  work  in  the  ~student/cs43l0  directory,  then  you  must  put  this  library  in  the  ~student/cs43IQ/ 
lib  subdirectory  and  you  must  ran  MEBuilder  from  ~student/cs4310. 

(2)  Move  the  appropriate  .cai  file  into  the  library's  parent  directory  (in  the  above  example,  it 
would  be  -student/c$4310. 

Note:  Included  in  the  library  ore  the  sample  lessons  built  under  the  demonstration  portions  of 
the  two  manuals  (prepjtircrqfl.cai  and  pilot jrainingJ.les.  respectively)  and  pilot jrainingJ .met  is  also 
available  for  running  in  METutor). 

DELIVERABLE*" 

The  required  deliverables  are  a  summary  of  your  work  with  the  two  systems  including  comments  about 
the  interface,  brief  script  runs  of  the  lessons  being  run  in  CAITutor  and  METutor  (no  need  to  show  a  complete 
ran,  just  enough  to  show  some  of  the  changes  you  made)  and  the  output  of  the  get_data  program.  The 
summary  should  not  exceed  two  pages  in  length. 


NOTES  CONCERNING  THE  USE  OF  MEBUILDER 

In  order  to  ensure  that  the  statistical  measurements  are  accurate,  your  use  of  MEBuilder  must  conform 
to  the  following  rales: 

a.  The  MEBuilder  lesson  will  contain  precisely  one  problem. 

b.  The  MEBuUder  lesson  will  be  based  on  precisely  one  task,  which  encompasses  the  entire  procedure 
being  taught. 

You  are  free  to  experiment  with  the  MEBuilder  lesson  structure  once  the  deliverable  statistical 
information  has  been  gathered. 
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TAB  2.  SUBJECT  MATTER  FOR  THE  EXPERIMENT  -  SUITE  ONE 


Lesson  One .  The  Scuba-Diving  Problem 

The  student  is  a  scuba  diver  who  plans  to  dive  for  lobster  from  an  anchored  boat.  The  lesson  focuses 
on  the  ability  of  the  student  to  self-equip  and  descend  to  the  sea  floor  to  get  the  lobster. 

At  the  start  of  the  problem,  the  student  will  be  inside  a  boat  wearing  no  scuba  gear.  At  the  end  of  the 
problem,  the  student  should  be  located  on  the  sea  floor  with  the  lobster  in  his  possession. 

Description  of  the  Procedure 

For  those  of  you  who  actually  scuba  dive,  you  will  note  that  this  is  a  subset  of  the  actual  procedure  used 
and  the  ordering  of  steps  is  more  restrictive  than  in  a  real  situation.  The  scope  has  been  reduced  in  order  to 
make  the  size  of  the  problem  manageable. 

The  student  has  the  following  gear  present  --  a  knife,  an  air  regulator,  an  air  tank,  a  weightbelt,  fins,  and 
a  mask.  Also  present  is  the  diver's  buddy.  You  do  not  specifically  have  to  model  the  buddy,  boat,  or  the 
lobster  (ways  to  do  this  are  given  below).  The  task  is  as  follows: 

(1)  The  diver  must  in  order  install  then  test  the  regulator,  and  mounts  it  on  the  air  tank. 

(2)  The  diver  dons  the  knife  and  the  weightbelt  and  dons  the  air  tank.  These  three  stepe  can  be 
done  in  any  order. 

(3)  The  student  then  dons  the  fins  and  mask,  and  checks  his  buddy's  tank.  These  three  steps  can 
be  done  in  any  order. 

(4)  The  student  then  in  order  valsalvos  to  clear  his  sinuses,  enters  the  water,  sets  the  tank  to 
negative  buoyancy  by  releasing  some  air,  then  descends  to  the  sea  floor  and  bags  the  lobster. 

Hints  and  Helpful  Information 

For  MEBuilder,  provided  are  the  objects  "diver",  "knife",  "air  regulator”,  "air  tank",  "weightbelt”, 
"fins",  and  "mask";  along  with  the  task  "prepare  diver".  The  lesson  is  not  provided,  you  will  build  it.  The 
CA1  lesson  is  in  prepare_diver.cai. 

In  CAlBuildei,  the  s»ates  in  the  lesson  are  numbered  in  order  start,  1, ...  ,  done.  When  following 
Appendix  B  of  the  CAIBuiider  manual,  pages  4  and  most  of  5  are  already  done.  Your  requirements  begin  at 
the  bottom  of  page  5. 

In  MEBuilder,  you  are  starting  at  the  point  where  the  initial  solution  is  completed,  bottom  of  page  54. 
Do  the  wotk  on  task  named  prepare  diver  command  to  reach  this  point. 


TAB  3.  SUBJECT  MATTER  FOR  THE  EXPERIMENT  -  SUITE  TWO 


Lesson  Two.  The  Cooling  System  Problem 

You  are  presenting  the  student  with  a  car  with  a  leaky  gasket  in  the  water  pump.  His  job  is  to  complete 
the  task  of  removing  the  water  pump,  replacing  the  gasket,  and  restoring  the  car  to  service. 

Hie  start  state  is  that  all  parts  of  the  engine  are  in  their  normal  configuration  -  that  is  to  say  the  radiator 
is  filled  with  fluid,  the  hoses  are  attached,  the  belts  are  in  place,  etc.,  etc.  You  want  the  student  to  have 
restored  the  engine's  condition  with  the  exception  of  the  new  gasket  being  in  place. 

Description  of  the  Procedure 

For  those  of  you  who  actually  work  on  cars,  you  will  note  that  this  is  a  subset  of  the  actual  procedure 
used  and  the  ordering  of  steps  is  more  restrictive  than  in  a  real  situation.  The  scope  has  been  reduced  in  order 
to  make  the  size  of  the  problem  manageable. 

The  student  is  only  going  to  be  concerned  with  the  following  items  on  the  car  -  the  engine  fan,  the 
radiator,  the  radiator's  hoses,  the  belts,  and  the  water  pump.  You  do  not  specifically  have  to  model  the  car. 
The  task  is  as  follows: 

(1)  The  mechanic  must  do  the  following  two  tasks  in  either  order: 

(a)  Unbolt,  then  remove  the  fan 

(b)  Drain  the  radiator,  then  remove  the  hoses 

(2)  The  mechanic  must  then  do  the  following  in  sequence  -  remove  the  belts,  unbolt  the  pump,  remove 
it,  replace  the  gasket,  install  the  pump,  then  bolt  it  in  place,  andreinstall  the  belts. 

(3)  The  mechanic  must  then  do  the  inverse  of  Step  (1)  above.  In  either  order: 

(a)  Install  the  fan,  then  bolt  it  in  place 

(b)  Install  the  hoses,  then  fill  the  radiator 

Hints  and  Helpful  Information 

For  MEBuilder,  provided  are  the  objects  "fan",  "radiator",  "hoses",  "water  pump' ,  along  with  the  task 
"replace  gasket".  The  lesson  is  not  provided,  you  will  build  it.  The  CAI  lesson  is  in  replace_gasket.cai. 

In  CAlBuilder,  the  states  in  the  lesson  are  numbered  in  order  start,  1 . done.  When  following 

Appendix  B  of  the  CAlBuilder  manual,  pages  4  and  most  of  3  are  already  done.  Your  requirements  begin  at 
the  bottom  of  pages. 

In  MEBuilder,  you  are  starting  at  the  point  where  the  initial  solution  is  completed,  bottom  of  page  54. 
Do  the  work  on  task  named  replace  gasket  command  to  reach  this  point. 
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TAB  4.  SAMPLE  RUN  OF  THE  DATA  COLLECTION  PROGRAM 


In  order  to  use  the  get_data  program,  you  must  be  in  the  directory  that  contains  the  special  file  user  .erg. 
The  task  created  from  MEBuilder  must  be  in  the  "lib’’  subdirectory.  The  resulting  text  file  will  appear  in  the 
mebuildxpt  file  in  the  working  directory.  The  following  is  a  get  data  session  with  user  inputs  highlighted. 

gemini : /users /workl/galvint/sample>>  -galvint /mebuild/get_data 


♦ - - - + 

I  MX BUILDER  Experiment  Data  Retrieval  and  Interpretation  I 
I  Program  --  Sxper intent  of  SQ  94  I 
+ - - - — - - - — - - - - - + 


Kane  the  CAX  file>  f laahlight ..repair, cai 
X  found  2  solutions  to  the  task. 

The  solution  has  14  nodes  and  14  transitions, 
dive  the  TASK  KAMI  --  not  the  file  name 
Name  the  MEBuilder  task>  flashlight  repair 
X  found  2  solutions  to  the  task. 

The  solution  has  8  nodes  and  7  transitions. 

You  will  now  be  asked  a  series  of  questions  regarding  the  amount  of 
time  you  spent  using  MEBuilder  and  CAXBuilder  and  how  that  time  was 
spent.  When  you  entire  "quit",  a  report  file  named  "mebuild.rpt" 
will  be  produced.  This  report  should  be  submitted  with  the  rest 
of  the  experimental  deliverables. 

DO  NOT  include  time  lost  due  to  CAXBuilder  or  MEBuilder  program  bugs. 

Please  give  integer  values  for  the  following.  Include  time  spent 
reading  through  the  materials,  practicing,  editing,  testing,  etc. 

How  many  hours  did  you  spend  on  the  CAX  task?  12 
How  many  hours  did  you  spend  on  the  MSB  task?  10 

You  will  now  provide  a  rating  list  of  the  areas  within  the  building 
process  that  you  spent  time  on. 

Please  express  your  answer  as  a  ‘permutation*  of  the  following  letters: 
f  d  e  t 

...the  order  must  be  of  most  time  spent  to  least  time  spent 
fafasdliarixation.  Reading  the  user’s  manual,  and  running  practice 
sessions  in  an  attempt  to  get  accustomed  to  the  process. 
d«de signing.  Time  spent  designing  the  objects  on  paper, 
e centering.  Time  spent  entering  the  lesson  data 
tatesting.  Time  spent  testing  and  "debugging"  the  end  result. 

Again,  please  answer  as  a  permutation  of  [f,d,e,t]  in  order  from 
most  time  spent  to  least  time  spent. 

Bow  did  you  spend  your  time  using  CAXBullder>  e  d  t  f 
How  did  you  spend  your  time  using  MEBuilder  >  t  e  d  f 

For  MEBuilder,  provide  your  response  the  same  way,  but  only  for  the 
naawd  subportion  of  the  process: 

Building  objects  in  MEBuilder  >  e  f  t  d 
Building  the  task  in  MEBuilder  >  t  d  e  f 
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Building  the  lesson  in  MEBuilder>  t  •  d  f 

The  report  baa  been  printed.  Thank  you  for  your  participation. 

The  following  is  the  sample  mebuild.rpt  produced  from  the  session. 

gaminii /usars/workl/galvint/sampla»  more  mebuild.rpt 
KBBuilder  Experiment  Report 
Sumner  Quarter  94 


1.  Comnand  usage  Comparison 

cax 

Number  of  Commands  Performed!  84 

Number  of  Comnands  Aborted!  6 

Percentage  of  Aborted  Comnands i  7.14k 

2.  Time  Usage  and  Effectiveness 

CAX  MSB 

Total  time  (in  hours) i  12  10 

Most  Time-Consuming  Process:  entering  testing 

2nd  Nost  Time-Consuming  Process:  designing  entering 

3rd  Most  Time-Consuming  Process:  testing  designing 

beast  Time-Consuming  Process:  familiar  familiar 

For  the  components  of  the  MEBuilder  process: 

OBJECTS  TASKS  LESSONS 

Most  Time-Consuming:  entering  testing  testing 

2nd  Most  Time-Consuming:  familiar  designing  entering 

3rd  Most  Time-Consuming:  testing  entering  designing 

Least  Time-Consuming:  designing  familiar  familiar 

3.  Lesson  Material  Produced 

CAX  MEB 

Number  of  Solutions  in  Lesson:  2  2 

Number  of  Nodes:  14  6 

Number  of  Transitions:  16  7 

gamini : /users /vorkl /galvint / sample?  > 


MEB 

95 

11 

11.57% 
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TAB  5.  INITIAL  DATA  FILES  FOR  SUITE  ONE 

This  tab  contains  the  CAIBuilder  lesson  and  the  MEBuilder  task  given  to  the  students  for  suite  one  of 
the  experiment.  The  MEBuilder  object  files  are  not  included  since  the  students  will  not  modify  them  as  part 
of  the  experiment. 

The  CAIBuilder  files  consist  of  caijiode(<node>)  facts  which  declare  the  valid  nodes,  and 
cai_step(<source  node>,  <operation>,  <message>,  <destination  node> )  which  declare  the  valid  transitions. 
As  with  MEBuilder,  the  start  and  done  nodes  are  reserved  for  the  beginning  and  completion  of  the  task.  The 
convention  used  for  CAIBuilder  is  to  name  die  nodes  the  same  as  the  MEBuilder  steps  in  the  task. 


ORIGINAL  CAIBUILDER  SOLUTION 


dynamic 
>-  multifile 
«-  dynamic 
<-  multifile 


type_of _prolog_f 11a/ 1 . 
typa_of_prolog_f  lla/1 . 
eai_lntro/l,  cai_step/4,  cai_noda/l. 
caijLntro/l,  cai_atap/4 ,  cai_noda/l. 


type_of_prolog_file( 'CAXBuild  Laaaon  Definition  fila'). 


/•  eai_intro/l  */ 

oai_intro(*  You  ara  a  scuba  diver  who  plana  to  diva  Cor  lobatar  from  an') . 
cai_intro( 'anchored  boat.  This  laaaon  will  focus  on  your  ability  to  self-'). 
cai_intro( 'equip  and  descend  to  the  save  floor  to  gat  the  lobster.'). 
aai_intro( ' 1 ) . 

cei_intro('  At  the  beginning,  you  will  be  in  the  boat  wearing  no  scuba'). 
cai_intro( 'gear.  The  gear  present  includes  a  knife,  a  regulator,  an  air'). 
cai_intro( 'tank,  a  waightbelt,  fins,  and  a  mask.  You  also  have  a  diving'), 
oai.intro ( 'buddy  present. ' ) . 
oai_intro (  " ) . 

cai_ intro ( '  The  lesson  will  end  once  you  have  reached  the  sea  floor  and'). 

cai_intro( 'bagged  the  lobster.  Good  luck!'). 


/*  oai_step/4  */ 

eai_stsp( start, [install, the, regulator] , 
('The' .regulator, is, now, installed] , 

»). 

eai_step(2, t turn, on, the, air) , 

('The', air, is, now, turned, on] , 

1). 

oai_step(3, [test, the, regulator] , 

['The' (regulator, is, working, fine] , 

4) . 

oai_step(4, [don,  the, knife] , 

[ 'You' , are, now, wearing, the, knits] , 

5) . 

oai_step(5, tdon,the,weightbelt] , 

[ 'You' , are, now, wearing, the,  weightbelt] , 

6) . 

aai_atap(6, [don, the, air, tank] , 
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t 'You' , are, now, wearing, tha, air, tank] , 

7). 

oai_etep(7, [don.the, tina] , 

('You', are, now, wearing, the, final , 

•). 

cai_atep(*, [don, the.maek] , 

['You'  , are, now, wearing, the, meek) , 

9) . 

cal_etep(9,  (cheek, your,  'buddy'  'a '  .tank] , 

('Your', 'buddy' 'a' .tank, appear a, to, be, 'OX'], 

10) . 

eal_atap(ll, [ralaaaa, air] , 

( 'Your' , cask, la, sow, negatively, buoyant] , 

12). 

oai_atap(10, (valaalvo] , 

[ ' You ' ,hava, olaarad, your , alnuaaa ] , 

' 10A ' ) . 

cai_atap ( • 10A • , tenter, the , water ) , 

( 'You'  ,are,now,in,the, water] , 

11). 

cei_atep(12,  [daacard] , 

('You' ,ara, now, on, tba,aaa, floor] , 

13). 

cal_atap(13, (bag, the.lobeter) , 

( ' You' ,bava,capturad,a,nlca,blg, juicy, lobatar] , 
dona) . 


/*  oai_noda/l  •/ 
c«i_aoda(atart) . 
eai_noda (dona) . 
cai_noda(2) . 
cai_noda ( 3 )  , 
cai_noda (4) , 
cai_noda(5) , 
cai_noda(6) . 
eaijnoda(7) . 
eai_node(«) . 
oai_noda(9) , 
caijnodatlO) . 
eai_noda (11) . 
cai_noda ( 13 ) . 
oal_noda( '10A' ) . 
cai_noda(13) . 


ORIGINAL  MEBUILDER  TASK 


s*. ***e*.***e**«*a«**.. •.*.»**.••*•*****. *•«•»****•*•»•., 
/*  MSPuildar  Task  Definition  Ylla  */ 
. . . . 


i-  dynamic 
i-  mltlfile 

»-  dynamic 


typa_of  _prolog_f lie / 1 . 
typa_of_prolog_f ila/1 . 

taak/3,  iaitlal_eenditiena/3,  objective*/!,  ataga/6, 
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aetion/6,  unordered_aetion/2 ,  relation/3. 

i-  multifile  twk/),  lnitial_conditiou/2,  objactlves/2,  ataga/t>, 
act  ion/ 1,  unorderad_action/  a ,  relation/3 . 


type_of_prolog_file( 'MXBuilder  Library  Task  Definition  File'). 


/•  task/3  */ 

taak ( tprapara ,  dJ  ver) , [diver , divar] , 
t [lobatar , lobatar ] ] ) . 


/•  initial_eonditions/2  ‘/ 
ialt ial_condit ions ( divar , 

[not ( ’baddy  checked' (divar) ) , 
not (claarad(divar) ) , 

■in  tba  boat1 (divar) , 
dotfedt 'diver' 'a ' .vaightbalt) , 
f £ad( 'divar* 's' .knife) , 

..  22ed(  'divar  •  'a '  ,naak) , 
doff ad ( 'divar' 'a • , final , 
resowed ( ' divar ' ‘ a ' , regulator ) , 
not (taatad) 'divar ' 'a' .regulator) ) , 
off ( 'divar' 'a' .air, tank) , 
doffed ( 'divar' 'a ' , air, tank) , 

'poeitivaly  buoyant' ( 'divar' ‘a ', air, tank) ) ) . 
initial_conditiona ( lobatar. 

(frae(lobeter)l) . 


/*  objectives/2  */ 
objectives (divar, 

['buddy  checked' (divar) , 
cleared (divar) , 

'on  the  aaa  floor ' (divar) , 
donned ( 'diver ' ' a ' , vaightbalt ) , 
donned ( 'diver' 'a ' .knifa) , 
donned ( 'diver' 'a ' ,naak) , 
donned ( 'divar ' ' a ' , f ina ) , 
installed ( 'diver' 'a' .regulator) , 
tasted ( ' diver  "  a ' » regulator) . 
on!  'diver' 'a' .air, tank) , 
donned ( 'diver' ' a ' .air, tank) , 

'  negatively  buoyant '  ( '  diver  "s',  air,  tarx )  ] ) . 
objectives (lobster, 

(captured (lobster) ] ) . 


/*  stage/ 6  •/ 

stage ( start , linear , none , linear , 

(). 

(1). 

stage ( ql , linear , none , linear , 
([start, 101. 1)1, 

(]>. 

stage jqa , linear , none , linear , 
[[ql, 102,1]], 

[]). 

stage (q3 , linear , none , linear , 
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IIq2. 103,111. 

(1). 

•tag*  ( q4 ,  llanr ,  none ,  1  inear , 

Itql, 104,111. 
m. 

•tag* { q5 , linear, none , 1 Invar , 

I[q4, 105,1]], 

m. 

•tag*  (qC ,  IIbmt  ,  mm  ,  lin**r , 

ItqS, 105,1]], 
tl). 

•tag* (q7 , linear , sob*, linear , 
tlqS, 107,1]], 

0). 

stag* (qt,lln*ar, non*, linear, 
[(<*7,105,1)), 

[]). 

•tag* (q9 , linear , non* , linear, 

Ilql, 109,1]], 
tl). 

•tag* (qlO , linear , non*, linear , 
Ctq9,li0,l]l, 

ID. 

•tag* (qll , linear , non*, linear , 
I[qi0,lil,U), 

ID. 

•tag* ( ql2 , linear , non* , linear , 
ttqll.lia.l]], 

ID. 

•tag* (ql3 , linear , non*, linear, 
tlql2, 113,1]], 

CD. 

•tag* (don* , no-act ion* , non* , linear , 
Itql3. 114,1]], 

ID. 


/•  action/ 6  */ 

act ion (101, install ( 'diver • '•* , regulator) , 
(], 

0, 

t), 

ID. 

action(102,t*st( 'diver' '■' .regulator) , 

I), 

I], 

I], 

ID. 

aation(103,turn(on, 'diver' '•', air, tank) , 

ID 

I], 

ID 

ID. 

act ion (104, don ( 'diver 1 '• ' ,w*ightb*lt) , 

(]. 

I], 

tl. 

ID. 

action (105, don ( 'diver' ' , knife) , 
tl, 

I], 
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net ion (IOC, don ( ' divar '  •  ,  air,  tank) , 

tl, 
ti, 
i). 
in. 

not ion (107, don ( ‘divar1 final, 

tl, 

II, 

ID 

ID. 

aotion(10»,don( 'divar ' 'a1, sank), 

(D 

tl. 

tl. 

ID. 

not ion (109, hava ( divar , chook ,  buddy ) . 
tl. 
tl. 
tl. 
tn. 

actionlllO, hava (divar, valanlvo) , 
tl. 
tl. 
tl. 
m . 

notion ( 111, hava (divnr, antar , tha,watar ) , 

tl. 

tl. 

II. 

ID. 

aation(112,r«lnaaa (air , f ro«,  ‘divnr1 ' a ' , air, tank) , 

tl, 

11. 

tl. 

ID. 

action(113, hava (divar, daacand) , 
tl. 
tl, 
tl. 
tl). 

aotion(114,bag(lobatar) , 
tl. 
tl, 
tl, 
tl). 


/*  unordnrod_nction/2  V 


/*  rnlation/3  */ 


TAB  6.  INITIAL  DATA  FILES  FOR  SUITE  TWO 


This  iab  contains  the  CAlBuilder  lesson  and  the  MEBu Drier  task  given  to  the  students  for  suite  two  of 
the  experiment.  The  MEBuilder  object  files  are  not  included  since  the  students  will  not  modify  them  as  part 
of  the  experiment. 

The  CAlBuilder  files  consist  of  cai_nede«Mdt>)  facts  which  declare  the  valid  nodes,  and 
cai jtt*p(<soutce  nodt>,  <openrton>,  <mtssage>,  destination  nodt>)  which  declare  the  valid  transitions. 
As  with  MEBuilder,  the  start  and  done  nodes  are  reserved  for  the  beginning  and  completion  of  the  task.  The 
convention  used  for  CAlBuilder  is  to  name  the  nodes  the  same  as  rite  MEBuilder  steps  in  the  task. 


ORIGINAL  CAIBUILDER  LESSON 


i-  dynamic 
»-  aultlfila 
t -  dynamic 
t-  suit if 11* 


typa_of_prolog_f iia/1 . 
typa_of _prolofl_f 11* / 1 . 
cai_iatro/l,  cai_atap/4,  cal_noda/l. 
cai_intro/l,  cai_atap/4,  eai_noda/l. 


typa_of_prolog_fila( 'CAXBuild  Laaaon  Definition  Pile'). 


/*  cai_intro/l  */ 

c»i_lntro ( •  lafort  you  la  a  oar  with  a  laaky  gaakat  In  tha  watar  pump . ' } . 
cai_intro( <Your  job  la  to  raplaca  tha  gaakat  and  raatora  tha  oar  to  lta'). 
cal_intro( 'working  condition. ' ) ■ 
e*l_lntro ( • ' ) . 

cai_intro( '  Tha  car  praaantly  haa  ita  fan,  bait a,  and  hoaaa  inatallad. ' ) . 
cal_ intro ( 1 Tha  radiator  la  full,  and  tha  watar  pump  la  in  plaoa.'). 
cai_intro ( " ) . 

cai_  intro ( •  flood  luck. ' ) . 


/•  cai_atap/4  •/ 

cal_atap ( a tart , [unbolt , tha , fan] , 

( • Tha • , t an, la • now, f ran] , 

a). 

cal_atap (2, (raaova.tha, fan] , 

('Tha',tan,ia.now,ramovad,from, tha, car] , 

3) . 

eai_atap(3, [drain, tha, radiator] , 

( 'Tha' .radiator, ia, now, traa, of , liquid] , 

4) . 

oai_atap(4,  [taaww.tho, hoaaa] , 

l 1  Tha*» hoaaa, hava, boon.- ranervad, from, tha, radiator] , 

5) . 

cat_atap(5, [ra*ova,tha,balta] , 

[' Tha', bolta, hava.baan.ramnvad) , 

«). 

eal_atap«,  [unbolt ,  tha, watar, punp] , 

['Tha' .watar, pu^p.ia, now, fraa] , 
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7). 

ea)_atap(7,  Imaw.tlw.wUi.piit) , 

[ 'Tha '.watar.punp,  la, now,  raawvad,  treat,  tha.  ear) , 

•  ). 

oal_atap(4, [raplaoa , tha , gaakat ] , 

( 'Tha 1  ,n«wlgulnt,bu,&M,b*»i  inatallad) , 

»). 

eai_atap(S, [inatall, tha.watar.puap] , 

l 'Tha' ,watar,puae,la,aow,rainatallad) , 

10). 

«ai_atap(10, [bolt, tha, watar, pun? ] , 

( '  lb* ' ,  watar ,  w ,  is  ,  now,  aarurad] , 

11). 

aal_atap(ll, [Install, tha, balta] , 

t 'Tha' , balta, ara, now, inatallad] , 

11). 

oal_atap(12. [install, tha, fan] , 
t 'Tha' ,  fan, la,aow,lh,placa] , 

11). 

oal_atap(ll, [bolt, tha, fan] , 

[•Tha' ,fan,ia,now,boltad, in, place] , 

14) . 

eai_atep(14, [install, the, hoses] , 

( ' The 1 , hoaaa , are .now, installed] , 

15) . 

cal_atop(lS, [fill, tha, radiator] , 

[' Tha '.radiator, la, now, '.Iliad. •], 
dona) . 


/•  oal_noda/l  */ 
cai_node (start) . 
cal_noda (dona) . 
oai_node(l) . 
oal_noda(l). 
oal_noda (4) , 
oai_node(S) , 
eai_node(C) . 
eai_noda(7) . 
cai_noda(») . 
oal_noda(9) . 
oai_noda(10) , 
eal_noda(ll) . 
oai_node(12) . 
caijoda(ll) . 
cal_noda(14) . 
eal_noda(15) . 

ORIGINAL  MEBUILDER  TASK 


. . 

/•  Mttulldar  Task  Definition  Flla  */ 

. . 


i-  dynaalc  type_of  _pr©log_fila/l. 

i-  aailtlf  11a  type_of_prolog_f ila/1. 
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i-  dyaanio  task/)-  inltlal_oohditloas/2,  objectives /a,  stage/*, 
action/*,  unordered_aotion/2 ,  relation/) . 

i -  aultlfile  task/),  lnltial_eoaditloas/2,  objectives/.,  stage/*, 
action/*.  uaorderad_aetioa/2,  relation/). 


type_of  j>roiog_f  ile( <MB*u  Ildar  Library  Teak  Definition  til*'). 


/*  task/)  •/ 

taakt (replace, gasket] ,  [character, character] , 
( t leer. engine] ,  tear , angina] ]  ] ) . 


/*  lnlt iei_condit Iona / 2  •/ 
initial_oooditiana t character , 

m. 

initial^  conditions ( (ear. engine] , 

[installed (oar, ' engine ' 'a 1 .belts) , 
installed (car, •engine' -a ' .hoses) , 
worn  (car. 1 engine ' •s', gasket), 
installed  (oar .  'engine'  'e 1 .water, pus©) , 
bolted  (car,  'engine'  's',  water,  pus©) , 
filled (car, 'engine' <a< .radiator) , 
installed (oar. 'engine' 'a '.fan), 
bolted (oar, 'engine' 's', fan)]) . 


/•  objectives/2  •/ 
obj act ivea ( character , 

m. 

objectives ( (oar, engine] . 

iinstalledlcar, 'engine' 's', belts) , 
installed (car . ' engine  "  a ' , hoses ) , 
serviceable ( car. ' engine ''s', gasket ) . 
lnstellad(cer,  'engine'  's '  .water, pungp) , 
bolted  (car, 'engine' 's' .water .gang) , 
filled (car , ' engine ' ' a ' , radiator) , 
installed (ear, 'engine' 's', fan), 
bolted (car, 'engine' 's' ,fan) ] ) . 


/*  stage/*  •/ 

stage ( start , linear , none , linear , 

I). 

m. 

stage (ql, linear, none, linear, 
lletart, 101,1]], 

ID. 

stage (q2 , linear, none , linear , 
ttqi.m.in, 

ID. 

stage (q) , linear, none , linear , 
Ctq2, 103.1)2, 

ID. 

stage (q4, linear, none, linear, 

{ tql , 104,1) ] , 

ID. 

stage (qS, linear , none, linear , 
ttq4, 105,1)1, 
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tJ). 

atage(qt, linear. none, linear. 

[ [qf , IOC, 1] ] , 

tl). 

a t age (q7, linear, none, linear, 

tm.  to?, iii. 

111. 

ataga (qt,  liMtr.MM.lluu. 

Uq7.10t.in, 

ID. 

ataga  (qt ,  Haiti ,  none ,  linear , 

Uqt.10t.il). 

m. 

•tag#  (qlO ,  Unit ,  bom  ,  linear . 

Uqt,  110,11), 

tl). 

atagafqll, linear, none,  linear, 
UqlO.111,1]), 
tl). 

ataga  (qia ,  11mu  ,  mm  ,  linear, 
Uqll.lia.l)  1, 
tl). 

atags (qll , linear,  none, linear, 

Uql2.llJ.in. 

ID. 

ataga  <ql4 , linear, none , linear , 
Uql3, 114,1]). 
tl). 

ataga (done, no- eat Iona, none, linear, 
Uqi4,U5,in, 

tn. 


/•  aotion/4  */ 

action (101, unbolt (car, 'engine' 'a* , tan) , 
tl. 
tl, 
tl. 
tl). 

actlon(10a,renove(car, 'engine' 'a' .Can) , 

I) , 
tl. 
t). 
tl). 

eetlan(103.draln(ear, 'engine' 'a' .radiator) , 
tl. 
tl, 
tl. 
tl). 

action(104,reuove(oar, 'engine' 'a'.hoeee), 

11. 

tl. 

tl. 

in. 

actlon(lOS,reuove(ear, 'engine' 'a* .belt a) , 
ti¬ 
ll, 
tl, 

II) . 

act lea (10C, unbolt (car, 'engine' 'a' , water, puag) , 

tl. 


be 
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t). 

ti. 

m. 

action) 107 , hww (w,  'angina1  ,watar,p\uv) , 
tl. 
tl. 

(It 

n>. 

aatiaa(lO(,raplaoa(aar,  'Mglw'  .gaakat) , 

(1. 

t). 

[). 

tl). 

utl«B(10lilutm(g«ti  'MfUt' 1  ■ 1  <w*t«r ,  puap) , 
tl. 
tl. 
tl. 
tl). 

actlonUlO,  bolt  lew, '  angina '  .watar.puap) , 

tl. 
tl. 
tl. 

ID. 

actiondll.lnatnlKcar, ' angina ' 'a'.balta), 
tl. 
tl. 

II. 

IJ). 

action! Ill, inatallfcar,  1  angle* '  'a'.tan), 
tl. 
tl. 
tl. 
tl). 

action (111, bole (car, 'angina' 'a'.fan), 
tl. 
tl. 
t). 
tl). 

action(114,laatall(car, 'angina ' 'a* ,boaaa) , 
t). 

n. 

ti. 

tn. 

act ion ( IIS, till (car , 'angina' 'a 1 .radiator) . 
tl. 
tl. 
t). 
tl). 


/*  unordaradLaatios/2  */ 


/*  ralation/3  •/ 
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TAB  7.  RAW  EXPERIMENTAL  DATA  COLLECTED 


For  the  row  headers  marked  in  italics,  the  following  is  the  legend: 

•  D  «  Time  spent  designing  the  task  (prior  to  running  the  authoring  system) 

*  E  =  Time  spent  entering  the  necessary  commands  into  the  authoring  system. 

•  F  »  Time  spent  familiarizing  (reading  the  manuals  and  running  the  sample  cases). 

*  T  ss  Time  spent  testing  and  debugging  the  lesson  in  the  ITS. 


Table  1:  Raw  Data  Collected  from  the  Data  Collection  Program 


Raw  Data  Per  Subject 

1 

2 

3 

n 

5 

6 

(D)iver  Problem  or  (E)ngine  Problem 

E 

D 

D 

E 

D 

■B 

(C)AIBuilder  first  or  (M)EBuilder  first 

C 

C 

C 

M 

M 

C 

Time  Spent  Using  CAIBuilder  (hours) 

2 

3 

3 

2 

1 

3 

lime  Spent  Using  MEBuilder 

3 

2 

2 

1 

1 

2 

Most  Time-Consuming  Process  (CAIIMEB) 

E/E 

D/E 

F/F 

F/F 

E/F 

F/F 

2nd  Most  Time-Consuming  Process  (CAIIMEB) 

D/F 

E/D 

T/T 

E/E 

F/E 

E/E 

3rd  Most  Time-Consuming  Process  ( CAIIMEB ) 

F/D 

F/F 

E/E 

D/D 

D/D 

D/D 

4th  Must  Time-Consuming  Process  ( CAIIMEB ) 

T/T 

T/T 

D/D 

T/T 

T/T 

T/T 

Number  of  CAI  Commands  Performed 

78 

140 

164 

151 

117 

68 

Number  of  CAI  Commands  Aborted 

1 

9 

3 

2 

0 

0 

Percentage  of  Aborted  Commands 

1.3 

6.42 

1.82 

1.33 

0.0 

0.0 

Number  of  MEB  Commands  Performed 

29 

25 

20 

11 

45 

unk* 

Number  of  MEB  Commands  Aborted 

9 

8 

1 

0 

6 

unk* 

Percentage  of  Aborted  Commands 

31.03 

32.0 

5.0 

0.0 

13.3 

unk* 

Number  of  Solutions  (actual  =  36) 

32 

36 

36 

4 

36 

36 

Number  Nodes/Transitions  in  CAI  Solution 

26/33 

23/32 

23/32 

23/38 

23/32 

23/32 

Number  Nodes/Transitions  in  MEB  Solution 

16/15 

14/13 

14/13 

16/15 

14/13 

14/13 

*  -  The  data  collection  program  failed  for  this  participant’s  MEBuilder  usage.  The  participant  stated 
that  his  usage  was  somewhat  on  par  with  his  peers. 


The  minimai  number  of  CAI  nodes  and  transitions  were:  for  the  diver  problem,  23  nodes  and  32 
transitions;  for  the  engine  problem,  24  nodes  and  31  transitions.  All  participants  achieved  the  minimal 
MEBuilder  data  structure. 
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TAB  8.  SELECTED  COMMENTS  FROM  THE  PARTICIPANTS 


The  vast  majority  of  the  comments  were  interface-related,  mostly  having  to  do  with  specific  program 
glitches,  the  cumbersomeness  of  the  command-line  interface,  or  complaints  about  the  help  system  (which  was 
not  fully  updated  in  time  for  the  experiment),  A  common  theme  among  the  interface  comments  was  the  call 
for  a  graphic-user  interface. 

The  comments  selected  below  were  those  which  specifically  addressed  the  focus  of  the  experiment  -  the 
respective  learning  curves  and  flexibility  of  the  two  methods. 

From  Participant  #3: 

“CAI:  Initial  I  found  the  concept,  manual,  and  help  very  confusing,  but  once  I  broke  the  code  it  went 
smoothly.  MEB:  [MEBuilder]  was  just  as  confusing  if  not  more  so  than  CAI.  I  was  not  sure  what  was  being 
provided  and  what  I  needed  to  create.  Once  I  broke  the  code  though,  it  saved  a  lot  of  time  as  compared  to 
CAI.” 

From  Participant  #4 

“...Both  are  frustrating  to  learn  (especially  when  you  aren’t  too  motivated).  But  once  you  get  going, 
neither  are  too  bad...Once  I  understood  what  to  do,  MEB  was  quick;  however,  1  wonder  if  it  would  have  been 
as  easy  if  the  post  &  pre  conditions,  etc.  weren’t  already  done...  A  menu-based  application  would  be  easier  for 
the  average  computer-phobic  to  use.” 

From  Participant  #6 

“...My  general  comments  are  that  both  systems  seem  fairly  straight  forward  to  use.  Actually, 
MEBuilder  seemed  much  more  complicated  and  I  don  ’  t  know  the  system  well  enough  to  make  a  fair  judgment 
of  what  this  additional  complication  got  me.  Not  actually  building  the  objects...left  me  wondering  what  v/as 
going  on....and  what  1  did  seemed  trivial  once  I  got  a  clue  as  to  what  I  was., .doing.” 
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